How to Verify and Troubleshoot Your DMARC, DKIM, and SPF Configuration

Start by looking up your domain's SPF record using a SPF lookup tool. Enter your domain and confirm the following:

A record exists. You should see a single TXT record starting with v=spf1. If nothing is returned, you don't have SPF configured. Skip to "What If I Don't Have an SPF Record?" below.

Only one SPF record exists. This is the most common SPF mistake. If your domain has two or more TXT records starting with v=spf1, the SPF check returns a permanent error and fails entirely. This often happens when switching email providers — the old record gets left behind. The fix is to merge everything into a single record.

All your sending services are included. Every service that sends email on your behalf needs to be authorized in your SPF record: your email provider (Google Workspace, Microsoft 365, etc.), marketing platforms (Mailchimp, HubSpot), transactional email services (SendGrid, Postmark, Amazon SES), CRM systems, helpdesk tools, and any other service that sends as your domain. Missing an include is the most common cause of SPF alignment failures in DMARC reports.

You haven't exceeded the 10-lookup limit. SPF allows a maximum of 10 DNS lookups per evaluation. Every include:, a, mx, redirect, and exists mechanism counts. If you exceed 10, the SPF check returns a permanent error. The fix is SPF flattening: replacing include: mechanisms with the underlying IP addresses.

Your record ends with the right qualifier. Use ~all (soft fail) while testing, then move to -all (hard fail) once you've confirmed all legitimate sources are passing. Never use +all — it authorizes every server on the internet to send as your domain.

DKIM verification is a two-part check: confirming the DNS record is published, and confirming your outgoing emails are actually being signed.

Check the DNS record. DKIM records are published at selector._domainkey.yourdomain.com, where "selector" is a name chosen by your email provider. Common selectors include google (Google Workspace), selector1/selector2 (Microsoft 365), k1 (Mailchimp), and s1/s2 (Amazon SES). If you don't know your selector, check a recent outgoing email's headers — look for the DKIM-Signature header and find the s= tag.

Verify outgoing emails are signed. Send a test email from your domain to an external address. Open the message, view the full headers, and look for DKIM-Signature. If it's present, your emails are being signed. Then check the Authentication-Results header — you want to see dkim=pass.

Check alignment with your From domain. DKIM signs mail with a specific domain (the d= value in the DKIM-Signature header). For DMARC to pass via DKIM, this domain must match your visible From address domain. A common problem: if you haven't configured a custom DKIM signature, your email provider signs with their own domain instead of yours — DKIM passes but DMARC still fails because the domains don't align.

If you use multiple sending services, each one needs its own DKIM configuration. Check that every service has a published DKIM key and is actively signing outgoing mail. Missing DKIM on even one service means those messages rely entirely on SPF for DMARC alignment.

Use the DMARC lookup tool to check your domain's DMARC record. Verify the following:

A record exists at _dmarc.yourdomain.com. If nothing is returned, you don't have DMARC configured. See "What If I Don't Have a DMARC Record?" below.

The syntax is valid. The record must start with v=DMARC1. Common syntax errors include missing semicolons between tags, extra spaces, and line breaks introduced by copy-pasting.

The policy (p=) is appropriate for your situation. p=none means monitor only; no messages are affected. p=quarantine sends failing messages to spam. p=reject blocks them entirely. If you're just getting started, p=none is correct. If you've been monitoring for a while and see clean reports, it's time to move to quarantine or reject.

The rua tag points to a working address. This is where DMARC aggregate reports are sent. If you're using Viewleaf, this should be your collector address. If rua is missing, you're not receiving any reports — which means you're enforcing a policy blind.

Check subdomain coverage. The sp= tag sets a separate policy for subdomains. Without it, subdomains inherit the parent domain's policy. Attackers often target subdomains specifically because they're overlooked.

This is the most common DMARC troubleshooting question, and the answer is almost always alignment failure.

DMARC doesn't just check whether SPF or DKIM pass — it checks whether the authenticated domain aligns with the domain in your From header. An email can pass SPF (the sending IP is authorized) but fail DMARC because the SPF-authenticated domain (the Return-Path) doesn't match the From domain.

The same applies to DKIM: an email can carry a valid DKIM signature, but if the signing domain (d= in the DKIM header) doesn't match the From domain, DMARC alignment fails.

How to fix it: Check your DMARC reports — in Viewleaf, the alignment status is shown for every source. Identify which sending sources are failing alignment, then reconfigure those services to either use your domain in the Return-Path (for SPF alignment), or sign with a custom DKIM key on your domain (for DKIM alignment). Most email services have documentation on how to set up custom authentication. Search for "[service name] custom DKIM setup" or "[service name] custom return path."

Without SPF, receiving servers have no way to check whether a sending IP is authorized by your domain. This removes one layer of authentication, makes DMARC alignment via SPF impossible, and leaves your domain more vulnerable to spoofing.

To add SPF, create a TXT record at your domain root (not a subdomain) with a value like:

v=spf1 include:_spf.google.com ~all

Replace the include: mechanism with the appropriate value for your email provider. If you use multiple sending services, list them all in a single record:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:amazonses.com ~all

After publishing, wait up to 48 hours for DNS propagation (though most changes take effect within minutes with Cloudflare or similar providers). Then verify with the SPF lookup tool.

Without DKIM, your outgoing emails aren't cryptographically signed, which means receiving servers can't verify the message hasn't been tampered with in transit. More importantly for DMARC, you lose one of the two possible alignment pathways — if SPF also fails to align, DMARC will fail.

To set up DKIM, configure it through your email provider, not directly in DNS:

1. Generate a DKIM key pair through your email provider's admin panel.
2. The provider gives you a DNS record to publish (a TXT or CNAME record at selector._domainkey.yourdomain.com).
3. Publish that record in your DNS.
4. Enable DKIM signing in your provider's settings.
5. Send a test email and verify the DKIM-Signature header is present.

Each sending service needs its own DKIM setup. Google Workspace, Microsoft 365, Mailchimp, SendGrid — each has its own process. Search for "[your provider] DKIM setup" for specific steps.

Without DMARC, you have no policy telling receivers what to do with unauthenticated email, and you're not receiving aggregate reports. This means you can't see who's sending email as your domain, whether your SPF and DKIM are working correctly, or whether anyone is spoofing you.

To add DMARC, create a TXT record at _dmarc.yourdomain.com with a value like:

v=DMARC1; p=none; rua=mailto:your-collector@viewleaf.com

Start with p=none so you're monitoring without affecting delivery. The rua address is where aggregate reports will be sent. If you sign up for Viewleaf (free during launch), you'll get a dedicated collector address and your reports will be parsed into visual dashboards automatically — no need to read raw XML.

Once you've monitored for a few weeks and confirmed your legitimate email sources are passing authentication, move to p=quarantine and eventually p=reject.

Email forwarding is one of the most common sources of DMARC failures that aren't caused by misconfiguration. When a message is forwarded, the forwarding server relays it from a different IP address, which breaks SPF (the new IP isn't in your SPF record). The forwarding server may also modify headers or message content, which can break DKIM.

The short answer: You can't prevent forwarding from breaking SPF. This is a known limitation of SPF. The solution is to make sure DKIM is properly configured and aligned. DKIM signatures survive forwarding as long as the message body and signed headers aren't modified.

If you see a pattern of DMARC failures from known forwarding sources (universities, older corporate mail systems, mailing lists), and DKIM is passing and aligned, those failures are expected and not a sign of spoofing. In your Viewleaf reports, you can identify these by looking for known forwarding infrastructure IPs with SPF-fail but DKIM-pass.

DNS changes typically propagate within minutes to a few hours, though the specification allows up to 48 hours. The TTL (Time to Live) value on your existing records determines how long old values are cached by resolvers.

For DMARC reporting specifically, there's an additional delay: DMARC aggregate reports are typically sent once per day by receiving mail servers. After publishing or updating your DMARC record, expect to wait 24–48 hours before reports start reflecting the change.

After making any DNS changes, verify the new records are live using Viewleaf's lookup tools: SPF Lookup, DMARC Lookup, and MX Lookup. If the old values are still showing, check the TTL on the record — it may simply need more time to propagate.