# How To Check SPF, DKIM And DMARC Before Sending

A two-pass pre-send check for SPF, DKIM and DMARC. Look up each DNS record, confirm alignment with your From domain, then read a test email's headers against Gmail, Yahoo and Outlook rules.

A new domain, a new sending tool or a first campaign all need the same pre-send check. Here is the workflow that proves your mail will authenticate before Gmail, Yahoo or Outlook judges it.

- Check SPF, DKIM and DMARC before sending in two passes, DNS records first, then a received test email.
- In DNS, look for one SPF record under 10 lookups, a DKIM key per sender and one DMARC record.
- DMARC passes only when SPF or DKIM passes on a domain aligned with your From domain.
- Gmail and Outlook require all three above 5,000 messages a day; Yahoo requires them for bulk senders.
- dmarcian, EasyDMARC and PowerDMARC check all three records free; MXToolbox looks up SPF and DKIM.

A DNS lookup proves the records exist. The headers of a received test email show whether they pass. Run the check for every new domain, every new sending tool and every DNS change. Passing authentication gets mail accepted for evaluation, but inbox placement still depends on spam complaint rates and sender reputation.

## How To Check SPF, DKIM And DMARC Before Sending

To check SPF, DKIM and DMARC before sending, list every service that sends as your domain and its DKIM selector, look up each DNS record, confirm alignment with your From domain, then send a test email and read its Authentication-Results header.

Most guides start at the record lookup. Start one step earlier, with the inventory. A typical B2B domain sends from a mailbox provider, a [cold email platform](https://growthtribune.com/best-cold-email-platforms/), a CRM, a billing system and a support desk. Each one needs its own place in SPF and its own DKIM key.

The DKIM selector is what makes this work. A selector lets one domain hold several public keys, one for each system, date range or third-party service. Without the selector list, you cannot look up every key.

- [ ] List every service that sends as your domain, its DKIM selector and who holds DNS access
- [ ] Check SPF for one record, every sender included and no more than 10 lookups
- [ ] Check DKIM once per selector, with a key of at least 1024 bits
- [ ] Check DMARC for one record with a policy and a reporting address
- [ ] Check that the SPF or DKIM domain aligns with your From domain
- [ ] Send a test email from each tool and read the Authentication-Results header
- [ ] Fix what failed, wait for DNS to update and run the check again

The sections below expand each step in that order. Keep the inventory as a living document, because every new tool someone connects needs its own SPF entry and DKIM key.

## What Gmail, Yahoo And Outlook Require From Senders

Gmail's [sender guidelines require SPF and DKIM, a DMARC record and a From domain aligned with the SPF or DKIM domain](https://support.google.com/mail/answer/81126?hl=en) for anyone sending more than 5,000 messages a day to Gmail accounts, and Yahoo and Outlook set the same three-part bar for their bulk senders.

These rules set the pass mark for every check in this workflow. They matter for any team whose [email deliverability](https://growthtribune.com/sales/email-deliverability/) depends on reaching Gmail, Yahoo or Outlook addresses.

**Authentication rules by mailbox provider**

| Provider | Applies to | Authentication | DMARC |
| --- | --- | --- | --- |
| Gmail | All senders | SPF or DKIM, PTR, TLS | Not required |
| Gmail | Over 5,000 a day | SPF and DKIM | p=none or stricter, From aligned |
| Yahoo | All senders | SPF or DKIM | Not required |
| Yahoo | Bulk senders | SPF and DKIM | p=none or stricter, must pass |
| Outlook | Over 5,000 a day | SPF and DKIM pass | p=none or stricter, aligned |

**Gmail:** Every sender needs SPF or DKIM, valid forward and reverse DNS (a PTR record for the sending IP), TLS and a spam rate below 0.3% in Postmaster Tools. Google recommends staying below 0.10%. Above 5,000 messages a day, Gmail adds SPF and DKIM together, a DMARC record (p=none is allowed), From alignment with the SPF or DKIM domain and one-click unsubscribe for marketing mail.

**Gmail enforcement:** Starting in November 2025, Gmail ramped up enforcement with temporary and permanent rejections of non-compliant mail. Postmaster Tools now has a Compliance status dashboard that bulk senders can use to see which rule they miss.

**Yahoo:** All senders need SPF or DKIM and a spam rate below 0.3%. Bulk senders need both, a DMARC policy of at least p=none that actually passes, a From domain aligned with SPF or DKIM (relaxed alignment is fine) and one-click unsubscribe.

**Outlook:** According to dmarcian's summary of Microsoft's rule, senders of more than 5,000 emails a day to outlook.com, hotmail.com and live.com must pass SPF and DKIM and publish DMARC at least at p=none, aligned with SPF or DKIM. Since May 5, 2025, non-compliant mail is rejected with error 550 5.7.15 instead of going to junk.

The practical reading is simple. If you send cold or marketing email at any scale, publish all three records and make at least one of them align. This summary is general information, not legal advice.

## How To Check Your SPF Record

An SPF record fails with a permerror once its evaluation needs more than 10 DNS lookups, because [RFC 7208 requires SPF checkers to stop at 10 DNS-querying terms](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4), so count includes before you add a new sending tool. Then confirm the record is the only one and that it lists every sender.

Look up the TXT records on your sending domain and find the one that starts with v=spf1. Then check four things, in this order.

1. **One record only.** RFC 7208 forbids a domain from publishing records that would select more than one SPF record. Two records break SPF for every sender.
2. **10 lookups or fewer.** The include, a, mx, ptr and exists terms and the redirect modifier each cost a DNS query, and nested includes count too. Past 10, the result is permerror.
3. **Two void lookups or fewer.** A void lookup is a query that returns no answer, usually an include pointing at a retired service. RFC 7208 says checkers should stop after two.
4. **Every sender present.** Compare the record with your inventory. A service missing from SPF fails SPF, even if everything else is clean.

Reading an include tree by hand is slow. dmarcian SPF Surveyor does the counting. It shows the DNS lookups the record needs, states when the record goes past the maximum of 10, shows includes as an expandable tree, lists the authorised netblocks and flags duplicates. Running it means agreeing to dmarcian's Public Tools Policy.

MXToolbox SPF lookup runs a set of SPF Validation diagnostics against the published record and highlights errors that could affect delivery. It works well as a second opinion on the live record.

To test a change before it reaches DNS, paste the draft record into the SPF Record Raw Checker from EasyDMARC. It validates an SPF record before you publish it, which catches a broken edit while the old record is still live.

> **Warning:** Many sending tools ask you to "add this SPF record" during setup. If you already have one, merge the new include into the existing record. Publishing a second v=spf1 record breaks SPF for every service on the domain.

When the lookup count is close to 10, remove includes for services you no longer use before you add a new one. The cleanest SPF record is a short one that matches the inventory exactly.

## How To Check DKIM

You check DKIM one selector at a time, because each sending service publishes its own public key at selector.\_domainkey on your domain, and Gmail requires that key to be at least 1024 bits long, with 2048 bits recommended. A domain-wide scan alone can miss a tool whose key was never published.

DKIM has no single record per domain. Each tool signs with its own private key and publishes the matching public key under its own selector. A domain-only scan can report "DKIM found" for one selector and still miss a tool whose key was never published.

**Find each selector:** Look in the sending tool's DNS or domain setup screen, where the selector appears in the host name it asks you to create. Or open a message the tool already sent and read the s= tag in its DKIM-Signature header.

**Look up each key:** With the selector in hand, run one lookup per tool.

- **MXToolbox DKIM lookup** retrieves the public key from a domain and a selector, entered together or as the full host name (selector.\_domainkey.yourdomain).
- \*\*brand:BR-724 DKIM Checker\*\* verifies that the public key is correctly published in DNS.
- \*\*brand:BR-723 Check MX\*\* takes your domain and an optional DKIM selector alongside its MX and SPF checks.

**Check the key length:** Gmail needs a key of 1024 bits or longer for personal Gmail accounts, and Google recommends 2048 bits where the DNS provider supports it. If a tool generated a shorter key, rotate it before the campaign.

> **Tip:** Write each tool's selector into your sender inventory the day you connect the tool. When DKIM fails months later, the selector list tells you in seconds which key to look up.

A key that resolves in DNS still only proves the key exists. Whether the tool signs with it, and with which d= domain, shows up only in a test email, which is where the alignment check comes in.

## How To Check Your DMARC Record

A DMARC check confirms one TXT record at \_dmarc on your domain with a p= policy and a reporting address, and [Yahoo's bulk sender rules accept p=none only if DMARC actually passes](https://senders.yahooinc.com/best-practices) on each message. Check the record after SPF and DKIM, since DMARC builds on both.

Look up the TXT record at \_dmarc.yourdomain and work through it tag by tag.

1. **Exactly one record.** Two DMARC records make the policy unreadable.
2. **Starts with v=DMARC1.** Anything before that tag invalidates the record.
3. **A p= policy.** The value is none, quarantine or reject.
4. **An rua= address.** Aggregate reports go here. Without it, you never learn which sources fail.
5. **The newer tags.** Under RFC 9989, the optional np= tag sets a policy for subdomains that do not exist, and t= marks test mode in place of the removed pct tag.

Two free tools read the record for you. The dmarcian DMARC Inspector parses the published record. The EasyDMARC DMARC Record Checker does the same, and its generator builds a new record if you have none.

**What p=none really does:** It meets the Gmail and Yahoo bulk-sender rule, and it applies no enforcement. Receivers still deliver mail that fails DMARC, so p=none proves you are compliant, not protected from spoofing. Treat it as the reporting phase before quarantine or reject.

**What Yahoo adds:** Yahoo's rule is that DMARC must pass, not merely exist. A published record with no aligned SPF or DKIM pass behind it meets neither Yahoo's bar nor Gmail's alignment rule. That is why the next check matters more than the record itself.

## How To Check DMARC Alignment

A message passes DMARC only when SPF or DKIM passes for a domain that aligns with the visible From domain, and RFC 9989 keeps relaxed alignment as the default, so a subdomain such as mail.example.com still aligns with example.com. You confirm it in the test email headers.

> **DMARC alignment:** DMARC alignment is the match between the domain that passed SPF or DKIM and the domain in the visible From address. A pass on an unaligned domain does not count toward DMARC.

This check explains why SPF can pass while DMARC still fails.

**Where each mechanism aligns:**

- **SPF** aligns on the Return-Path (envelope from) domain, shown as smtp.mailfrom in the headers.
- **DKIM** aligns on the d= domain in the DKIM signature, shown as header.d or header.i.

**Relaxed and strict:** In relaxed mode, the organisational domains must match, so mail.example.com aligns with example.com. In strict mode, only an exact match aligns. RFC 9989 keeps relaxed as the default for both adkim and aspf, so unless your record sets s, relaxed applies.

**One aligned pass is enough.** DMARC passes if at least one mechanism passes on an aligned identifier. You do not need both to align.

**The common failure:** Many sending services use their own domain as the default Return-Path. SPF then passes for the service's domain, which does not match your From domain, so SPF does not align. There are two fixes.

1. **DKIM with your domain.** Have the tool sign with d=yourdomain. An aligned DKIM pass carries DMARC on its own.
2. **A custom return-path.** Set up a return-path subdomain on your domain in the tool's settings, which brings SPF into alignment.

Doing both gives you a backup when one mechanism breaks, for example when forwarding strips SPF.

**How to check it:** Take a test email from each tool and compare three domains in its headers.

**The three domains to compare**

| Header value | What it shows | Aligned when |
| --- | --- | --- |
| header.from | Visible From domain | The reference domain |
| smtp.mailfrom | Return-Path domain for SPF | Same organisational domain |
| header.d or header.i | DKIM signing domain | Same organisational domain |

If either smtp.mailfrom or the DKIM domain shares an organisational domain with header.from, and that mechanism passed, alignment holds.

## How To Send A Test Email And Read The Authentication Results

A received test email shows whether SPF, DKIM and DMARC work, through an Authentication-Results header that reads spf=pass, dkim=pass and dmarc=pass, with the passing domains matching the From address. Send one from every tool that uses your domain, and read the header line by line.

Send a real message from each sending tool, not a test from your own mailbox. Send it to a Gmail inbox you control and open Show original, or send it to a checker address. Use the same From address, tool and settings the campaign will use.

The receiving server writes its verdict into the Authentication-Results header. Here is an illustrative example for example.com.

**Example Authentication-Results header**

```txt
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounce@mail.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com
```

Read it line by line.

- **dkim=pass header.i=@example.com** means the DKIM signature verified for example.com. The header.s value is the selector the tool used.
- **spf=pass smtp.mailfrom=bounce@mail.example.com** means the sending IP is allowed by the SPF record of mail.example.com, which aligns with example.com in relaxed mode.
- **dmarc=pass header.from=example.com** means at least one aligned pass was found. The p= value shows the policy the receiver read.

If dmarc shows fail while spf shows pass, compare smtp.mailfrom with header.from. That gap is the alignment problem from the previous section.

**Tools that read the result for you:**

- **EasyDMARC Email Header Analyzer** takes a pasted header, an EML file or an email sent to its address. It reports SPF, DKIM and DMARC results, blacklist status, DNS checks, a SpamAssassin score and the routing path. Only received emails carry complete headers, so paste from the received copy.
- **MXToolbox deliverability test** works when you send a test email to ping@tools.mxtoolbox.com. The reply links to a report on the message headers, the blacklist reputation of the outbound IP and SPF. For DKIM and DMARC verdicts, read the Authentication-Results line yourself or use a header analyzer.
- **Google Admin Toolbox Messageheader** analyses pasted headers to find delivery delays and their approximate source across hops. It is a delay tracer, not an authentication checker.

Repeat the test for every tool in the inventory. One passing tool says nothing about the others.

## Which Tools Check SPF, DKIM And DMARC

The SPF, DKIM and DMARC checkers from dmarcian, EasyDMARC and PowerDMARC each look up all three record types, MXToolbox looks up SPF and DKIM and runs a test-email check, and Google Admin Toolbox covers MX and SPF and traces delivery delays in headers. The right one depends on which step you are checking.

The table maps each toolset to the steps above. It is a map of what each one checks, not a ranking.

**Checkers by step**

| Tool | Checks | Input | Header or test email | Access |
| --- | --- | --- | --- | --- |
| MXToolbox | SPF and DKIM | Domain and DKIM selector | Ping address test | Web lookup |
| dmarcian | SPF, DKIM and DMARC | Domain | Header Analyzer | Tools policy applies |
| EasyDMARC | SPF, DKIM and DMARC | Domain and DKIM selector | Header Analyzer | Work email for report |
| PowerDMARC | SPF, DKIM and DMARC | Domain | Header Analyzer | No account |
| Google Admin Toolbox | MX and SPF | Domain, optional selector | Delays only | Web tools |

**MXToolbox** suits quick single lookups and the test-by-email route. Its DKIM lookup needs the selector.

**dmarcian** SPF Surveyor shows the lookup count, expands includes as a tree, lists netblocks and flags duplicates. dmarcian also offers DKIM Inspector, DKIM Validator, the DMARC Record Wizard and an XML-to-human converter for DMARC reports.

**EasyDMARC** pairs each checker with a generator, including the SPF Record Raw Checker for testing a record before you publish it. The full Domain Scanner report arrives by email and needs a work email address.

**PowerDMARC** offers an all-in-one Domain Analyzer and a DKIM Generator that creates a key pair, with no account needed.

**Google Admin Toolbox** gives you Check MX for MX and SPF and Dig, a web version of the Unix dig command, for raw DNS answers.

**What drives cost beyond the checkers:** Paid EasyDMARC DMARC plans scale by emails per month, number of domains and months of report history. PowerDMARC bills on outbound DMARC-compliant mail only, with plans that scale by email volume and active domains.

> **Limitation:** The MXToolbox deliverability report covers the headers, outbound IP reputation and SPF, so DKIM and DMARC verdicts still need a header read. Google Admin Toolbox Messageheader shows delivery delays rather than authentication verdicts. Every DKIM lookup needs the right selector to find the key.

## What Changed In DMARC With RFC 9989

[RFC 9989, published in May 2026, replaces RFC 7489 as the DMARC standard](https://datatracker.ietf.org/doc/html/rfc9989), removes the pct tag in favour of a t= test-mode flag, and adds an np= policy for subdomains that do not exist. It also obsoletes RFC 9091, and it changes how receivers find your organisational domain.

RFC 9989 is a Proposed Standard. For a pre-send check, four changes matter.

- **pct is gone.** The old pct tag applied a policy to a percentage of failing mail. RFC 9989 removes it. The new t tag marks the policy as being in test mode, and test mode does not affect report generation.
- **np is new.** The np tag sets the policy for subdomains that do not exist.
- **A DNS tree walk.** Receivers now find the organisational domain with a DNS tree walk instead of relying only on the Public Suffix List.
- **Alignment defaults stay relaxed.** Both adkim and aspf still default to r, so existing relaxed setups keep aligning as before.

**What to check in an existing record:**

1. Remove pct if your record still has it. The t tag now marks a policy as being in test mode.
2. Decide on an np value for subdomains that do not exist.
3. Keep rua in place, because reports are how you judge any policy change.

> **Note:** Older checkers may still parse pct and show it as valid. A checker that accepts the tag tells you the record is readable, not that the tag still does anything under RFC 9989.

## Why SPF, DKIM Or DMARC Fail After A Clean Check

SPF, DKIM and DMARC can fail after a clean pre-send check when mail is forwarded, when a new tool sends without its DKIM key or when an SPF include grows past 10 lookups, and [Gmail's rejection codes name the requirement that failed](https://support.google.com/a/answer/14229414).

A pre-send check is a snapshot. These are the five ways a clean snapshot goes stale, with the fix for each.

1. **Forwarding.** When a recipient forwards mail, the forwarder becomes the sending server and SPF breaks. DKIM survives if the message is unchanged, and ARC can carry the earlier results to receivers that trust it. The fix is an aligned DKIM signature, so DMARC does not depend on SPF.
2. **A new tool without its key.** Someone connects a new tool and skips the DKIM step, so its mail sends unsigned or signed with the vendor's domain. The fix is to add every tool to the inventory before it sends, and run the test email for it.
3. **A second SPF record.** A setup wizard publishes a fresh v=spf1 record next to the old one. The fix is to merge the include into one record and delete the duplicate.
4. **Lookups past 10.** A vendor adds a nested include to its own SPF, and your count crosses the limit without any change on your side. The fix is to re-run SPF Surveyor after adding any include, and prune unused services.
5. **DKIM key rotation.** A tool rotates to a new selector and the old record is removed before the new one is live. The fix is to publish the new selector first, confirm it in a test email, then retire the old one.

**How to catch them:** Gmail's temporary failure messages include error codes that point to the sender requirement causing the failure, so read bounces closely. Bulk senders can also watch the Compliance status dashboard in Postmaster Tools.

The risk grows with each sender. A [cold email platform sends from mailboxes you own](https://growthtribune.com/what-is-a-cold-email-platform/), so every new mailbox, domain and tool adds one more record to keep in line.

## When To Move From Checking To DMARC Monitoring

Move from one-off checks to DMARC report monitoring once more than one or two services send as your domain or before you tighten p=none to quarantine, because aggregate reports show which sources send as your domain and whether they pass.

**The decision rule:**

- **One-off checks are enough** for a single domain with one or two senders that you set up yourself.
- **Move to monitoring** when you run several sending tools or domains.
- **Move to monitoring** before you change p=none to quarantine or reject.
- **Move to monitoring** when you suspect services are sending as your domain that are not in the inventory.

Aggregate reports arrive at the rua address as XML files. One report is readable with dmarcian's free XML-to-human converter, which is enough to spot a missing sender. Reading reports every week across several domains is where a paid monitoring tool earns its place.

**What drives the cost of paid monitoring:**

- **EasyDMARC** plans scale by emails per month (tiers from 100,000 to 5,000,000), the number of domains and how many months of data history you keep. Deliverability and Enterprise plans are priced through sales.
- **PowerDMARC** bills on outbound DMARC-compliant mail only, with no charge for phishing or invalid mail sent on your domain's behalf. Basic scales across volume tiers from 50,000 to 2,000,000 emails with 5 active domains.

**EasyDMARC pricing**

| Plan | Price | Billing | Notes |
| --- | --- | --- | --- |
| DMARC Plus | $44.99 | per month |  |
| DMARC Premium | $89.99 | per month |  |
| Deliverability | Custom pricing | per custom |  |
| Enterprise: Email Trust | Custom pricing | per custom |  |

**PowerDMARC pricing**

| Plan | Price | Billing | Notes |
| --- | --- | --- | --- |
| Free | $0 | per month |  |
| Basic | $15 | per month |  |
| Enterprise | Custom pricing | per custom |  |
| Partner Program | Custom pricing | per custom |  |

DMARC monitoring covers authentication only. If you also need to know where mail lands, inbox or spam, compare the [email deliverability tools](https://growthtribune.com/best-email-deliverability-tools/) built for placement testing.

## FAQ

**Do I need SPF, DKIM and DMARC, or is one enough?**

Gmail and Yahoo let low-volume senders get by with SPF or DKIM alone. Above 5,000 messages a day to Gmail, or as a Yahoo bulk sender, you need SPF, DKIM and DMARC together, with an aligned From domain. Publishing all three covers both cases and leaves room to grow.

**Can a domain have two SPF records?**

No. RFC 7208 says a domain must not publish records that would select more than one SPF record. Two v=spf1 records cause SPF to fail for every service on the domain. When a new tool asks you to add an SPF record, merge its include into the existing record instead.

**What DKIM key length does Gmail require?**

Gmail requires a DKIM key of at least 1024 bits for mail sent to personal Gmail accounts. Google recommends 2048 bits wherever your DNS provider supports keys that long. If a sending tool generated a shorter key, rotate it to a new selector before you start the campaign.

**Is a DMARC policy of p=none enough to send to Gmail and Yahoo?**

Yes, p=none meets the Gmail and Yahoo bulk-sender rules, but Yahoo requires DMARC to pass, so an aligned SPF or DKIM result must sit behind it. A p=none policy applies no enforcement, so it keeps you compliant without protecting the domain from spoofing.

**Does email forwarding break SPF?**

Usually, yes. When mail is forwarded, the forwarder becomes the sending server, so SPF fails for your domain. DKIM survives if the message content is unchanged, and ARC can preserve earlier results for receivers that trust it. An aligned DKIM signature keeps forwarded mail passing DMARC.

## Sources

- [Email sender guidelines - Gmail Help](https://support.google.com/mail/answer/81126?hl=en), support.google.com
- [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4), datatracker.ietf.org
- [Sender Best Practices | Sender Hub](https://senders.yahooinc.com/best-practices), senders.yahooinc.com
- [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)](https://datatracker.ietf.org/doc/html/rfc9989), datatracker.ietf.org
- [Email sender guidelines FAQ - Gmail Help](https://support.google.com/a/answer/14229414), support.google.com

---
Source: https://growthtribune.com/how-to-check-spf-dkim-and-dmarc-before-sending/