Email Authentication Check: Verify SPF, DKIM, and DMARC Step by Step

An email authentication check answers two related questions: can your domain’s authorized systems send mail, and did a particular message actually authenticate when a recipient received it? The reliable answer comes from checking both DNS records and real message headers—not from seeing a record exist in a DNS dashboard.

What an email authentication check actually tests

Email authentication is a set of DNS-based and cryptographic controls that helps a receiving mailbox decide whether a message claiming to be from your domain is legitimate. The core controls are SPF, DKIM, and DMARC. They are designed to reduce sender spoofing, a technique commonly used in phishing and business-email-compromise attempts. (learn.microsoft.com)

An effective check has two layers:

1. Domain configuration: Are the required DNS records published, syntactically valid, and consistent with every service that sends as your domain?
2. Message-level results: Did a test email receive spf=pass, dkim=pass, and dmarc=pass at the recipient—and did the authenticated identity align with the visible From: domain?

The distinction matters. A valid-looking SPF record does not prove that your transactional email platform is included. A DKIM public key in DNS does not prove your provider is signing messages with the matching selector. And a DMARC record set to p=none provides visibility, but it does not ask receiving systems to quarantine or reject unauthorized mail.

For day-to-day operations, treat email authentication as a delivery and security control rather than a one-time DNS project. Your configuration changes whenever you add a new sending source: Google Workspace or Microsoft 365, a product-email API, a support desk, an invoicing tool, a CRM, an event platform, or an agency’s campaign system.

SPF, DKIM, and DMARC: what each check proves

SPF checks the sending infrastructure

Sender Policy Framework, or SPF, lets a domain owner publish the hosts or networks authorized to send mail for a domain. A receiver evaluates the SMTP envelope identity—commonly exposed to recipients as Return-Path—against the published SPF policy. SPF does not authenticate the friendly display name or, by itself, the visible From: address that readers see. (datatracker.ietf.org)

A simple SPF record might look like this:

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

The important pieces are:

• v=spf1 identifies the TXT value as an SPF policy.
• include:_spf.google.com delegates authorization to another SPF record.
• -all states that sources not matched earlier should fail SPF.

SPF works well for authorizing known infrastructure, but it has a hard operational constraint: SPF evaluation limits DNS-querying terms to 10. Nested include, a, mx, exists, ptr, and redirect mechanisms can consume that budget. Going over it can produce permerror, which is not an acceptable passing result. (datatracker.ietf.org)

DKIM checks a signed message

DomainKeys Identified Mail, or DKIM, attaches a cryptographic signature to selected headers and the body of a message. The recipient retrieves a public key from DNS and verifies the signature. In practical terms, a passing DKIM result shows that the message was signed by a domain that controls the corresponding private key and that the signed parts were not altered after signing. (datatracker.ietf.org)

A DKIM signature commonly includes fields such as:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

Here, d=example.com is the signing domain and s=mail2026 is the selector. The receiver looks up this DNS hostname:

mail2026._domainkey.example.com

The resulting TXT record includes a public key, commonly in a form similar to:

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

Your email platform normally generates the DKIM records and signs mail for you. Do not invent a selector or public key: copy the exact DNS hostnames and values supplied by the service. DKIM supports RSA-based signatures and the Ed25519-SHA256 algorithm defined by RFC 8463; supported options depend on the sending vendor and recipient ecosystem. (datatracker.ietf.org)

DMARC connects authentication to the visible From domain

Domain-based Message Authentication, Reporting, and Conformance, or DMARC, builds on SPF and DKIM. It tells recipients how to handle messages that fail authentication and lets the domain owner request reports about observed mail streams. The current DMARC specification is RFC 9989, which obsoletes RFC 7489. (datatracker.ietf.org)

DMARC does not require both SPF and DKIM to pass on every message. A DMARC pass requires at least one of SPF or DKIM to pass and for the passing domain to align with the visible author domain in the From: header. Alignment may be relaxed or strict. (rfc-editor.org)

That alignment requirement explains a common surprise:

• SPF passes for bounce.vendor-mail.net.
• DKIM passes for vendor-mail.net.
• The visible sender is news@example.com.
• Neither authenticated domain aligns with example.com.
• Result: DMARC can fail even though SPF and DKIM each show a pass.

For most organizations, DKIM alignment is the easier durable path for third-party senders. Configure each provider to sign with your domain or a subdomain you control, such as d=mail.example.com, rather than only with the vendor’s domain.

Start with an inventory, not a DNS editor

Before changing records, make a complete list of every system that can send mail using your domain in the visible From: field. This avoids the most damaging authentication mistake: publishing a strict DMARC policy before discovering a legitimate sender.

Include at least these categories:

• Employee mailboxes, such as Google Workspace or Microsoft 365.
• Product and transactional email, such as password resets, receipts, alerts, and invitations.
• Marketing automation and newsletter platforms.
• Customer-support and ticketing systems.
• CRM sequences and sales-engagement tools.
• Accounting, subscription, and invoicing software.
• Website forms, WordPress plugins, and server-side applications.
• Any agency, franchise, or regional team that sends campaigns independently.

For each source, record the visible From domain, envelope/return-path domain, DKIM signing domain, DKIM selector, sending IPs or vendor SPF include, owner, and business purpose. You need this inventory to interpret DMARC reports later; a report can show an unfamiliar source, but it cannot tell you whether that source is an attacker, an old integration, or a legitimate tool owned by another team.

If you are building product email, make authentication an explicit part of your sending-provider setup checklist. The provider-specific DNS instructions and API sending requirements should be documented alongside your application configuration; the email API setup guides are the right place to keep that operational runbook current.

How to run a DNS email authentication check

You can use a browser-based checker, but command-line lookups make it easier to see precisely what public DNS returns. On macOS and Linux, use dig. On Windows, use nslookup -type=TXT or PowerShell’s Resolve-DnsName.

Check SPF

Run:

dig TXT example.com +short

Look for exactly one TXT value beginning with v=spf1. Your domain may have many TXT records for unrelated services, so do not mistake a domain-verification token for SPF.

A combined record for a company using Google Workspace plus an application sender might resemble:

v=spf1 include:_spf.google.com include:spf.sender.example -all

The second include is illustrative only. Use the exact include hostname issued by your actual email provider. Do not publish multiple SPF records such as one record for Google and another for a marketing platform. SPF expects a single policy record; merge authorized mechanisms into one record while staying within the DNS lookup limit. (datatracker.ietf.org)

What success looks like:

• One v=spf1 record exists at the sending domain.
• Every active sender is represented directly or through a vendor-provided include.
• The policy ends with an intentional qualifier, commonly -all once the inventory is complete.
• Your SPF evaluator reports fewer than 10 DNS-querying terms.

Check DKIM

DKIM requires a selector, so you cannot reliably check it from the root domain alone. Find the selector in your provider configuration or send a test message and read its DKIM-Signature header.

If the selector is mail2026, run:

dig TXT mail2026._domainkey.example.com +short

A successful lookup returns a DKIM TXT value or, for some providers, a CNAME that eventually points to the vendor’s DKIM hostname. Either model can work. What matters is that the public DNS path resolves and that real messages show dkim=pass for the intended signing domain.

Avoid manual key editing unless your mail server software requires it. Long DKIM keys can be split into multiple quoted TXT-string chunks by a DNS provider; DNS concatenates those chunks. That formatting is usually normal. More concerning signs are a missing record, a selector typo, an invalid CNAME target, or a message signed with a different s= selector than the record you checked.

Check DMARC

DMARC always lives beneath the _dmarc label. Run:

dig TXT _dmarc.example.com +short

A basic monitoring record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

A stricter enforcement record can be:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

The essential tags are:

• v=DMARC1 — the protocol version marker.
• p=none, p=quarantine, or p=reject — the requested handling policy for mail that fails DMARC.
• rua=mailto:... — the destination for aggregate reports.
• adkim=r and aspf=r — relaxed DKIM and SPF alignment. Relaxed alignment is appropriate for many organizations that use controlled subdomains.

Receiving systems ultimately make their own delivery decisions, so a DMARC policy is not a mathematical guarantee that every failed message will be rejected. But p=quarantine and p=reject clearly express your intended treatment of unauthenticated, unaligned mail, whereas p=none is monitoring mode. (support.google.com)

Worked example: authenticate a SaaS company’s sending domain

Assume a fictional company, Acme Tasks, sends employee mail from Google Workspace and product mail through a transactional provider. Its public sender is updates@acmetasks.com, and its product mail uses a custom return path at bounce.acmetasks.com.

Step 1: publish a unified SPF record

Acme verifies what Google Workspace and its transactional provider each require. It then publishes one SPF TXT record at acmetasks.com:

v=spf1 include:_spf.google.com include:spf.transactional-provider.example -all

This is an example pattern, not a copy-and-paste vendor configuration. The transactional provider’s include hostname must come from that provider’s documentation. The organization then runs an SPF lookup-count check to ensure the nested records remain under the SPF limit.

Step 2: enable provider DKIM with an aligned domain

The transactional provider supplies either DKIM TXT records or CNAME records for a selector such as tx1._domainkey.acmetasks.com. Acme adds exactly what the provider gives it, verifies DNS, and turns on DKIM signing in the provider dashboard.

The desired outbound header later resembles:

DKIM-Signature: ... d=acmetasks.com; s=tx1; ...

A signing domain of acmetasks.com directly aligns with From: updates@acmetasks.com. A signing domain of mail.acmetasks.com normally aligns under relaxed alignment because it shares the same organizational domain. A signing domain owned only by the provider does not align.

Step 3: start DMARC in monitoring mode

Acme publishes:

v=DMARC1; p=none; rua=mailto:dmarc-reports@acmetasks.com; adkim=r; aspf=r

The reporting address should be a mailbox or reporting service that the company actively monitors. Aggregate reports are machine-readable XML, often compressed, so a dedicated DMARC reporting tool can make them easier to interpret. The point of this period is to identify all sources claiming to send as acmetasks.com and find failures before enforcement.

Step 4: send a live test

Acme sends one message from an employee mailbox and one from the product-email system to separate Gmail and Outlook.com test inboxes. Using more than one receiver matters because each mail system can display diagnostics differently and applies its own filtering logic.

In the received header, Acme looks for a result structurally similar to:

Authentication-Results: ... spf=pass ...; dkim=pass header.d=acmetasks.com; dmarc=pass header.from=acmetasks.com

Microsoft 365 documents that received messages include an Authentication-Results header showing SPF, DKIM, DMARC, and related authentication assessments. (learn.microsoft.com)

Step 5: enforce after report review

Once reports show that legitimate sources pass and align, Acme can move from p=none to p=quarantine, then to p=reject. The pace is a risk decision, not a universal timer. Move only when you understand the sources that appear in reports and have either authorized, migrated, or retired them.

This process gives Acme a defensible success condition: its intended senders authenticate in real messages, its domains publish an enforcement policy, and report data no longer reveals unexplained legitimate traffic that would break under enforcement.

How to check a real email’s authentication headers

A DNS audit tests what you intended to configure. Message headers test what actually happened in transit. Do both after every provider change.

In Gmail, open the message menu and use Show original. In Outlook clients, use the message properties or view source option available in that client. Find the Authentication-Results header and the DKIM-Signature header.

Prioritize these fields:

Do not stop at green-looking SPF and DKIM results. Read the domains following them. This header fragment is healthy for a message from alerts@example.com:

spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

This fragment needs investigation even though two components pass:

spf=pass smtp.mailfrom=mailer.vendor.test; dkim=pass header.d=vendor.test; dmarc=fail header.from=example.com

The second message proves the difference between basic authentication and DMARC alignment. The provider is authorized to send as itself, but it has not established an aligned identity for example.com.

The most common email authentication failures and fixes

Multiple SPF records

Symptom: a DNS checker reports more than one v=spf1 record, or received mail shows spf=permerror.

Why it happens: teams add a new TXT record each time they adopt a new sender instead of extending the existing SPF policy.

Fix: retain one SPF record, merge authorized mechanisms, remove obsolete services, and count DNS-querying mechanisms after every change. Never merge records by copying random includes from blog posts; use each sender’s official domain-authentication instructions.

SPF passes but DMARC fails

Symptom: spf=pass appears in headers but dmarc=fail does too.

Why it happens: SPF authenticates the envelope sender, while DMARC compares the authenticated domain to the visible From: domain. A vendor-owned return path may be valid for SPF but not aligned with your brand domain.

Fix: configure a custom return-path or custom MAIL FROM domain if the provider supports it, or make sure aligned DKIM passes. For third-party email, aligned DKIM is often the practical solution.

DKIM selector not found

Symptom: dkim=fail, dkim=temperror, or a lookup for selector._domainkey.example.com returns no usable record.

Why it happens: the record is missing, DNS has not propagated according to its TTL, a selector was mistyped, or the service signs with another selector.

Fix: copy the selector from the actual DKIM-Signature header, then compare the exact DNS hostname and value with the provider’s setup screen. Re-enable signing only after DNS resolves correctly.

DMARC is published but only monitors

Symptom: the record contains p=none, and unauthorized messages may still reach recipients.

Why it happens: monitoring mode is intentionally non-enforcing. It is useful during deployment but is not the end state for a domain that needs spoofing protection.

Fix: review aggregate reports, correct legitimate failures, then advance to p=quarantine or p=reject based on your operational confidence and tolerance for false positives.

A vendor signs with its own domain

Symptom: a marketing or support platform reports DKIM enabled, but the message header shows d=vendor.example rather than your domain.

Why it matters: DKIM can pass without helping DMARC for your visible From domain.

Fix: complete the platform’s custom-domain authentication flow. This usually means publishing CNAME or TXT records that delegate a DKIM selector under your domain. Confirm the result in a received message, not only in the vendor UI.

Forwarding or mailing lists break SPF

Symptom: messages sent through a forwarder show spf=fail even though the original sender is legitimate.

Why it happens: SPF evaluates the IP address that delivered the message to the final receiver, and forwarding infrastructure is generally not listed in the original sender’s SPF policy. Microsoft explicitly documents SPF failure after forwarding as expected behavior. (learn.microsoft.com)

Fix: ensure original messages use aligned DKIM, because an intact DKIM signature can allow DMARC to pass when SPF fails. ARC may preserve prior authentication assessments across intermediaries, but it is supplemental metadata for receivers—not a replacement for aligned SPF and DKIM. (datatracker.ietf.org)

A safe DMARC rollout plan

The safest order is discovery first, enforcement later. Skipping the discovery stage can block password resets, invoices, support replies, or campaigns sent by forgotten systems.

1. Inventory every sender. Include all subdomains and country or product brands.
2. Publish one valid SPF policy. Remove services that no longer send mail.
3. Enable DKIM for every sender. Prefer a signing domain aligned with the visible From domain.
4. Publish p=none DMARC with aggregate reporting. Use a monitored reporting destination.
5. Review report data. Classify every meaningful sending source as legitimate, unauthorized, retired, or unknown.
6. Fix alignment failures. Configure custom DKIM, custom return paths, or a dedicated sending subdomain.
7. Move to p=quarantine. Watch reports and support tickets for unintended consequences.
8. Move to p=reject. Continue monitoring because vendors, DNS settings, and internal systems change.

Google’s sender guidelines require all senders to personal Gmail accounts to use SPF or DKIM, while senders that meet Google’s bulk-sender threshold must use SPF, DKIM, and DMARC. Google defines that threshold as approximately 5,000 messages to personal Gmail accounts in a 24-hour period and notes that bulk classification is persistent once assigned. (support.google.com)

That makes authentication a practical deliverability baseline, even for a startup that is not yet sending high volume. An authenticated domain does not guarantee inbox placement—content, user complaints, reputation, and recipient-specific policies still matter—but unauthenticated mail begins with a major trust disadvantage. (dmarc.org)

Use subdomains to control risk and simplify operations

A useful architecture is to separate human, transactional, and marketing mail by subdomain. For example:

• example.com for employee mail.
• notify.example.com for product events and transactional email.
• news.example.com for newsletters and promotional campaigns.
• support.example.com for customer-service platforms.

This is not mandatory, but it narrows the blast radius of a vendor mistake and makes DMARC reports easier to interpret. It also lets teams manage distinct reputations and sender identities without forcing every provider into the root domain’s SPF record.

If you use subdomains, publish and check authentication records for each domain that appears in a visible From: address. A root-domain DMARC policy can apply to subdomains under some conditions, but explicit records make intent clearer when different systems and policies are involved. Test each subdomain independently with a real message.

For product teams, the key decision is not whether a provider offers an API. It is whether the provider supports domain verification, DKIM signing, custom return paths where needed, and observability that lets you prove authentication continues to work. Compare that operational fit alongside transactional email pricing, because the least expensive sending tier is not inexpensive if it creates a fragile authentication workflow.

How to know the email authentication check worked

A successful setup has evidence at three levels.

DNS level

• One SPF record exists for each sending domain.
• Active DKIM selectors resolve through TXT or provider-required CNAME records.
• A DMARC TXT record exists at _dmarc.yourdomain.
• There are no malformed tags, duplicate SPF policies, dead includes, or unexpected DNS lookup-limit failures.

Message level

Send from every platform, not just your primary mailbox. At the receiving inbox, verify:

• spf=pass for the expected envelope domain where SPF is applicable.
• dkim=pass for your domain or an aligned subdomain.
• dmarc=pass for the visible From domain.
• The From:, Return-Path:, header.d=, and header.from= values match the architecture you intended.

Reporting level

Aggregate DMARC reports should show authorized sources passing at a high and stable rate. More important than any arbitrary percentage is that you can explain every nontrivial source and failure category. Unknown senders trying to use your domain are a reason to strengthen enforcement; known senders failing authentication are a reason to fix configuration before doing so.

Re-run this check whenever you change email providers, migrate DNS, add a new SaaS sender, rotate DKIM keys, alter a return-path domain, or change the address used in From:. Authentication failures are often introduced by ordinary operational changes—not by someone intentionally weakening security.

FAQ

What is the fastest way to do an email authentication check?

Check public DNS for SPF, DKIM, and DMARC, then send a real message to Gmail or Outlook and inspect Authentication-Results. DNS confirms that records are published; the received header confirms that your actual sender used them successfully.

Can SPF pass while DMARC fails?

Yes. SPF validates the envelope sender domain, while DMARC requires a passing SPF or DKIM domain to align with the visible From: domain. A third-party sender can pass SPF under its own domain and still fail DMARC for yours. (rfc-editor.org)

Do I need both SPF and DKIM if DMARC only requires one aligned pass?

Yes, in normal production use you should deploy both. SPF can fail when mail is forwarded, and DKIM can fail if a message is modified in transit. Using both gives receivers more reliable signals and meets major sender requirements for bulk mail. (support.google.com)

Does p=none protect my domain from spoofing?

No. p=none is primarily a monitoring policy: it asks receivers to send reports but does not request quarantine or rejection for mail that fails DMARC. Use it to discover legitimate sources, then move to an enforcement policy when the data supports it. (support.google.com)

Is email authentication the same as verifying an email address?

No. Email address verification checks whether an individual address is plausible or reachable. Email authentication verifies whether a message and its sending domain satisfy SPF, DKIM, and DMARC checks. Both can improve sending quality, but they solve different problems.