How to Verify SPF and DMARC Records for Any Domain

// What Are SPF and DMARC?

Email spoofing — forging the "From" address to impersonate a trusted sender — remains one of the most common attack vectors on the internet. Two DNS-based standards help receiving mail servers decide whether an incoming message is legitimate: SPF and DMARC.

SPF (Sender Policy Framework)

SPF is a TXT record that lists which IP addresses and mail servers are authorised to send email on behalf of your domain. When a receiving server gets a message claiming to be from you@example.com, it checks whether the sending server's IP appears in your SPF record.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC builds on SPF and DKIM. It tells receiving servers what to do when authentication fails (nothing, quarantine, or reject) and where to send aggregate reports about failures. A typical DMARC record looks like:

Without both SPF and DMARC properly configured, anyone can send email that appears to come from your domain — damaging your reputation and enabling phishing against your customers.

// How to Read TXT Records

Both SPF and DMARC are published as DNS TXT records. You can query them with dig, nslookup, or an online domain lookup tool like ip-tracker.online.

SPF record location

SPF records are published at the root of your domain (or occasionally at a subdomain). Look for a TXT record starting with v=spf1.

DMARC record location

DMARC records are always at _dmarc.yourdomain.com. Look for a TXT record starting with v=DMARC1.

Example: google.com

Google maintains industry-standard email authentication. A lookup of google.com reveals:

The SPF record uses include:_spf.google.com to delegate authorised senders to a shared Google SPF list. The ~all mechanism means "soft fail" for servers not in the list. DMARC uses p=reject, the strictest policy — unauthenticated mail claiming to be from Google should be rejected outright.

// Common Misconfigurations

Even experienced administrators make mistakes with email authentication. Here are the issues we see most often when auditing domains:

Multiple SPF records

A domain must have exactly one SPF TXT record. If you publish two records starting with v=spf1, SPF evaluation fails entirely — which means SPF provides no protection. Merge all authorised senders into a single record using include: mechanisms.

Too many DNS lookups

SPF evaluation is limited to 10 DNS lookups (includes, a, mx, redirect, etc.). Exceeding this limit causes a permanent error. Flatten your SPF record or use an SPF flattening service if you send through many third-party platforms (Mailchimp, Salesforce, Zendesk, etc.).

Missing DMARC entirely

SPF alone does not prevent spoofing — it only helps receiving servers evaluate the sending IP. Without DMARC, there is no policy telling receivers what to do with failures, and no reporting to alert you when someone impersonates your domain.

DMARC p=none left forever

Many organisations deploy DMARC with p=none for monitoring, then never graduate to p=quarantine or p=reject. Monitoring-only DMARC collects reports but does not protect recipients from spoofed mail.

SPF/DKIM pass but DMARC fail

DMARC requires alignment — the "From" domain must match the domain used in SPF or DKIM. A message can pass SPF for a mailing service domain while failing DMARC because the visible "From" header shows your domain. This is a frequent cause of legitimate mail being rejected after tightening DMARC policy.

// Step-by-Step Verification with IP Tracker

You can verify SPF and DMARC manually with command-line DNS tools, but a domain lookup on ip-tracker.online consolidates TXT records, highlights SPF/DMARC status, and shows related DNS configuration in one view. Here is a practical workflow:

1. Open ip-tracker.online and enter the domain name (e.g. google.com).
2. Review TXT records — look for v=spf1 at the root domain and v=DMARC1 at _dmarc.
3. Check SPF status — confirm a single SPF record exists, count include mechanisms, and verify the all qualifier matches your policy intent.
4. Check DMARC policy — note the p= value (none, quarantine, or reject) and confirm rua= points to a mailbox you monitor.
5. Cross-check MX records — ensure your mail exchangers match the servers authorised in SPF.
6. Review SSL certificate — while not directly related to email auth, a valid TLS cert on your mail-related subdomains indicates overall domain hygiene.
7. Document findings — screenshot or export results for your security audit trail.

For domains you manage, run this check after every DNS change involving email — adding a new marketing platform, migrating to Google Workspace or Microsoft 365, or onboarding a transactional email provider like SendGrid or Amazon SES.

// Fixing Problems You Find

If SPF is missing

Create a TXT record at your domain root. Start conservatively:

Replace the include with your actual mail provider's SPF documentation.

If DMARC is missing

Add a TXT record at _dmarc.yourdomain.com. Start with monitoring:

After two to four weeks of reviewing aggregate reports and fixing alignment issues, move to p=quarantine, then p=reject.

If you use multiple senders

Combine them in one SPF record:

Count your DNS lookups — if you approach 10, consider SPF flattening or removing unused includes.

// Testing After Changes

DNS changes can take minutes to 48 hours to propagate globally. After updating SPF or DMARC:

• Re-run the domain lookup on ip-tracker.online to confirm the new records are visible.
• Send a test email from each authorised platform to a Gmail or Outlook account.
• Inspect the message headers for spf=pass, dkim=pass, and dmarc=pass.
• Use external validators like MXToolbox or dmarcian if you need a second opinion.
• Monitor DMARC aggregate reports for unexpected failure sources.

Email authentication is not a one-time setup. Re-verify whenever you add a new sending service, change DNS providers, or acquire a domain that previously sent mail through different infrastructure.

// Related Articles