Email authentication protocols are the DNS-based controls that let receiving mail systems determine whether a message claiming to be from your domain is legitimate. Correctly deploying SPF, DKIM and DMARC protects your brand from impersonation and improves the odds that legitimate campaigns reach the inbox.

They are not a single switch, nor are they a guarantee of inbox placement. Email authentication is a system: you must inventory every sender, publish correct DNS records, align identifiers, read reports, and enforce policy carefully. This guide explains the protocols, record syntax, failure modes, and a practical rollout you can follow.

What email authentication protocols do

A normal email address is easy to forge. The visible From: header is text chosen by the sender, so an attacker can send a message that appears to be from ceo@example.com without controlling example.com. This is the core reason phishing and business-email compromise frequently use trusted brands and internal domains.

Email authentication protocols give mailbox providers evidence to evaluate that claim. They answer related but different questions:

SPF asks whether the server that sent the message is authorized to use a domain in the SMTP envelope sender.
DKIM asks whether a domain cryptographically signed the message and whether protected content survived transit unchanged.
DMARC asks whether SPF or DKIM passed and aligns with the domain a recipient sees in the From: header. It also publishes the domain owner’s requested handling policy and reporting addresses.
ARC preserves authentication assessment through intermediaries such as mailing lists and forwarding services. It does not replace SPF, DKIM, or DMARC.

Other related standards solve adjacent problems. MTA-STS and DANE for SMTP concern encryption and server identity during mail transport, not sender-domain authentication. BIMI can display a brand indicator at supporting mailbox providers, but normally depends on a strong DMARC posture and, for many implementations, a verified mark certificate. Do not treat BIMI as a substitute for DMARC.

The identifiers that cause most confusion

One email can contain several domain names. Understanding them is essential:

Header From domain: the human-visible address, such as news@example.com. DMARC evaluates alignment against this domain.
SMTP envelope sender, also called MAIL FROM, return-path, or bounce domain: for example, bounce.mail.example.com. SPF evaluates this domain.
DKIM signing domain, shown as d= in the DKIM-Signature header: for example, example.com or mail.example.com.
HELO/EHLO domain: the name a sending server announces during SMTP. SPF can evaluate it when there is no envelope sender, but it is not the primary DMARC identifier.

A message can pass SPF and still fail DMARC if SPF authenticated an unrelated bounce domain. Likewise, it can pass DKIM but fail DMARC if the DKIM d= domain does not align with the visible From domain. This distinction is why a green SPF result alone is not proof that your anti-spoofing deployment works.

SPF: authorize sending infrastructure

Sender Policy Framework is published as a DNS TXT record. A recipient checks the message’s connecting IP address against the SPF policy for the envelope-sender domain. SPF is specified in RFC 7208.

A basic record might be:

example.com. IN TXT "v=spf1 ip4:198.51.100.24 -all"

This says that IPv4 address 198.51.100.24 may send mail using an envelope sender at example.com; all other senders should fail. The documentation IP above is illustrative—replace it with your actual sending IP or vendor mechanisms.

Common SPF mechanisms and qualifiers

SPF policies begin with v=spf1 and then list mechanisms. The most common are:

ip4: and ip6: authorize explicit IP ranges.
a authorizes addresses returned for the domain’s A or AAAA record; a:mail.example.com uses a specified host.
mx authorizes addresses of the domain’s MX hosts.
include: evaluates another domain’s SPF policy, which is common for email platforms.
exists: is an advanced DNS lookup test and should be used only with a clear operational reason.
all matches everything and is normally last.

A qualifier controls the result: + pass (the default), - fail, ~ softfail, and ? neutral. For an established, fully inventoried sending domain, -all is the clearest policy. A temporary ~all may be useful during discovery, but it is not a durable substitute for knowing your senders.

A realistic record for a company that sends through its own relay and a marketing vendor could resemble:

example.com. IN TXT "v=spf1 ip4:203.0.113.44 include:spf.marketing-vendor.example -all"

Use the exact include domain supplied by your vendor; never guess it from a sample. A vendor may require a custom bounce subdomain rather than a root-domain include, which is often better for DMARC alignment and sender separation.

SPF limits and design traps

SPF has a major operational constraint: evaluation can trigger no more than 10 DNS-query-causing lookups. The lookup-counting mechanisms include include, a, mx, exists, redirect, and some ptr behavior. Nested includes count too. Exceeding the limit produces an SPF permerror, not a pass.

Avoid multiple SPF TXT records at the same hostname. A domain must publish one SPF policy record; multiple records can yield a permanent error. A domain can publish other TXT records, such as verification tokens, but only one v=spf1 record.

SPF also breaks under conventional forwarding. The forwarding server often sends the original message from its own IP, which was not authorized by the original envelope-sender domain. Sender Rewriting Scheme (SRS) can address this at forwarding services, while DKIM and ARC offer complementary resilience. This is one reason SPF alone cannot protect a visible From address.

DKIM: sign mail so recipients can verify it

DomainKeys Identified Mail adds a cryptographic signature in the message headers. The signing system uses a private key; the receiver retrieves a corresponding public key from DNS. If verification succeeds, the receiver knows that the signing domain authorized the signature and that signed fields and body content have not changed in a way that invalidates it.

A simplified header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mta1;
 h=from:to:subject:date:message-id; bh=...; b=...

Here, d=example.com is the signing domain and s=mta1 is the selector. The recipient looks up:

mta1._domainkey.example.com

The TXT response contains a DKIM public key, commonly in a form similar to:

mta1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

The public-key value is generated by your mail platform; do not manually fabricate it. Many providers present the record in an admin console and may split a long value across DNS interface fields. Follow that provider’s formatting guidance, but ensure the final DNS response is a single valid TXT value from the verifier’s perspective.

DKIM choices that matter

Use a unique, meaningful selector per service or key generation, such as google, m365, transactional1, or a date-based rotation label. Selectors make it possible to rotate a compromised or retiring key without disrupting every sender.

Modern deployments should use sufficiently strong keys. Many providers support RSA 2048-bit keys; some receivers may not accept 1024-bit DKIM keys. DNS providers and mail vendors differ in supported algorithms and record presentation, so generate keys in the actual sending platform and test their published output.

The d= domain should be the visible From domain or an organizationally aligned subdomain whenever possible. For a message from billing@example.com, d=example.com is strict alignment; d=mail.example.com is relaxed alignment, assuming example.com is the organizational domain. A signature from vendor.example may pass DKIM technically but does not align with example.com for DMARC.

DKIM can fail when an intermediary modifies signed material. Mailing lists may add a subject prefix, footer, or recipient header. Some gateways rewrap message bodies. Forwarding usually preserves a valid DKIM signature better than SPF, but modifications can still invalidate it. Sign the From header, avoid unnecessary content rewriting, and use ARC-aware handling where appropriate.

DMARC: connect authentication to the visible From domain

Domain-based Message Authentication, Reporting, and Conformance is the policy layer. It tells a receiver what to do when mail claiming to be from your domain fails DMARC, and it enables aggregate feedback reports. DMARC is specified in RFC 7489, although mailbox-provider enforcement behavior is provider-specific.

A starter record is placed at _dmarc.example.com:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

The record means:

v=DMARC1: protocol version and required first tag.
p=none: request monitoring only; do not ask receivers to quarantine or reject based on the policy.
rua=: destination for aggregate XML reports.
adkim=r and aspf=r: relaxed DKIM and SPF alignment. Relaxed is the default if omitted.
pct=100: apply the requested policy to all applicable mail. It is useful only after moving to quarantine or reject.

DMARC passes if at least one of these conditions is true:

SPF passes and the authenticated SPF domain aligns with the header From domain.
DKIM passes and the DKIM d= domain aligns with the header From domain.

This OR logic gives resilient senders two routes to DMARC pass. In practice, configure both SPF and DKIM for every legitimate platform. That protects deliverability when forwarding breaks SPF or a provider changes an IP address, and it makes troubleshooting far easier.

Relaxed versus strict alignment

Under relaxed alignment, a subdomain can align with its organizational domain. Thus bounce.mail.example.com can align with example.com, and d=mail.example.com can align with example.com, subject to public suffix domain rules.

Under strict alignment, the domains must match exactly. These settings request strict alignment:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"

Strict alignment can be appropriate for a tightly controlled domain, but it frequently exposes third-party sender configuration gaps. Start with relaxed alignment unless your mail architecture and risk requirements justify strict mode. Alignment is independent for SPF and DKIM: you can set one strict and the other relaxed, although doing so increases operational complexity.

DMARC policies: none, quarantine, and reject

DMARC policy is a request to receivers, not an absolute command. Each recipient system applies local fraud, reputation, and delivery rules too.

p=none gathers visibility without asking for special disposition. It is the right starting point, but it does not stop spoofing.
p=quarantine asks recipients to treat failing mail suspiciously, commonly by placing it in spam or quarantine.
p=reject asks recipients to reject failing mail during delivery. It is the strongest anti-spoofing policy.

A staged path may use these records:

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

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com"

Do not advance simply because a dashboard says “most” mail authenticates. Review all legitimate traffic categories, including password resets, invoices, product notifications, support systems, recruiting systems, CRM campaigns, accounting software, scanners, and executive assistants sending through delegated tools.

DMARC reports, subdomains, and privacy

Aggregate reports, requested with rua, are XML files generally sent on a receiver-defined cadence. They summarize observed IP addresses, counts, authentication results, dispositions, and identifiers. They do not normally contain message bodies, but they can reveal sending infrastructure and volume patterns, so secure the report mailbox and limit access.

For an external report address—for example, rua=mailto:reports@dmarc-processor.example—DMARC requires external destination authorization. The report recipient publishes a TXT authorization record at a name based on the sending policy domain, such as:

example.com._report._dmarc.dmarc-processor.example. IN TXT "v=DMARC1"

This prevents a domain owner from redirecting report traffic to an arbitrary third party without that party’s consent. A DMARC reporting vendor normally gives you the exact record and destination address to use.

Forensic or failure reports use ruf, but their availability and contents vary substantially by receiver because they can create privacy and data-handling concerns. Do not rely on them as your main diagnostic feed. Aggregate reports plus message-header tests are the operational foundation.

DMARC policy can cover subdomains through sp=. For example:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com"

This applies reject to the organizational domain and quarantine to subdomains that do not publish their own DMARC record. A dedicated subdomain, such as marketing.example.com, can publish _dmarc.marketing.example.com to establish its own policy.

ARC and why forwarded email is difficult

Authenticated Received Chain, defined in RFC 8617, lets intermediaries record their authentication evaluation and seal that record cryptographically. ARC headers include ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal.

The common use case is a message that passes SPF, DKIM, and DMARC when first received by a mailing list or gateway but is altered or resent before reaching the final mailbox. The final receiver may see broken SPF and DKIM. If it trusts the intermediary’s ARC chain under its local policy, it can consider the earlier authentication result.

ARC is not a domain-owner policy and has no DNS record you add instead of DMARC. It depends on receiving systems deciding which ARC sealers they trust. Domain owners should still deploy SPF, DKIM, and DMARC. Operators of forwarding, list, and security services should evaluate ARC support and proper sealing as part of their mail architecture.

A worked example: authenticate a SaaS company domain

Assume a SaaS company owns northstar.example. It sends employee mail through Microsoft 365, marketing campaigns through a platform that supports a custom sending domain, and transaction emails through an application provider. The company wants mail with From: northstar.example to authenticate without accidentally blocking legitimate receipts and alerts.

Step 1: create a sender inventory

Make a spreadsheet with these columns: system owner, product, visible From domain, envelope/bounce domain, sending IP or vendor include, DKIM selector, monthly volume, and business criticality. Ask finance, marketing, support, IT, product, HR, and agencies—not just the email administrator.

The inventory may reveal that marketing uses news@northstar.example, product uses alerts@northstar.example, and a help desk sends support@northstar.example. Each must either produce aligned SPF or aligned DKIM, ideally both. A vendor that can only sign with its own domain must be reconfigured or moved to a dedicated sending subdomain that it can authenticate correctly.

Step 2: publish and validate SPF

Microsoft 365 documents an SPF include domain for its service, while each external provider supplies its own mechanism or custom-domain instructions. The conceptual final result may be:

northstar.example. IN TXT "v=spf1 include:spf.protection.outlook.com include:spf.transactional-vendor.example -all"

This is an example only: do not copy a vendor include unless that vendor documents it for your account and region. Check the resulting record with a DNS lookup tool and an SPF lookup tool that displays the recursive lookup count. If it approaches 10, reduce unnecessary includes, move services to purpose-specific subdomains, or redesign the sending arrangement rather than using unsafe “SPF flattening” without a process to track vendor IP changes.

Step 3: enable DKIM on every sender

In the Microsoft 365 admin experience, enable DKIM for the custom domain after publishing the CNAME records Microsoft provides. In the transaction and marketing platforms, set d=northstar.example or a related aligned subdomain and publish their assigned DKIM records. Vendor interfaces often use CNAME delegation rather than a raw TXT public key; that is normal when the vendor manages key rotation.

Send a test to a mailbox you control and inspect original headers. Look for dkim=pass and check that the authenticating header.d= or DKIM d= is northstar.example or an aligned subdomain. A passing signature from the vendor’s unrelated domain is insufficient for DMARC alignment.

Step 4: start DMARC in monitoring mode

Create a dedicated address such as dmarc-reports@northstar.example, or use a reporting processor after completing its authorization record. Publish:

_dmarc.northstar.example. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r; fo=1"

The optional fo=1 expresses a request for failure reporting when any underlying authentication mechanism fails, but actual report behavior is receiver-dependent. Aggregate reports remain the useful evidence source.

For a meaningful observation period, review reports across normal business cycles and campaigns. Identify every source that sends meaningful volume. Classify unfamiliar sources: they may be attackers, a forgotten vendor, forwarded mail, shadow IT, or a provider using infrastructure you did not recognize.

Step 5: fix alignment, then enforce

Suppose reports show the help desk passes DKIM with d=helpdesk-vendor.example but uses From: northstar.example. Configure custom DKIM in the help-desk product if offered. If it cannot support an aligned domain, change the visible From address to a domain you control and can authenticate, or replace the sending setup.

Once legitimate mail consistently passes DMARC, move deliberately from p=none to p=quarantine, using pct=25 if you need a limited rollout. Investigate unexpected failures, then increase coverage and eventually set p=reject; pct=100. Keep monitoring after enforcement: new SaaS tools and agency campaigns can introduce unauthenticated senders at any time.

How to test and prove the configuration works

DNS publication alone is not proof. Test the actual mail stream from each sending system, because a valid record can coexist with a platform that is not using it.

Use three levels of validation:

DNS checks: query TXT and CNAME records with dig, nslookup, or a reputable DNS checker. Confirm the exact hostnames, no duplicate SPF policy, and no typos caused by DNS UI quoting.
Message-header checks: send from every platform to Gmail, Outlook.com, or a controlled test mailbox. Open the raw source and inspect Authentication-Results for spf=pass, dkim=pass, and dmarc=pass, plus aligned domains.
Report checks: use DMARC aggregate data to verify real production sources, IPs, volume, and pass rates. Header tests tell you whether one message works; reports tell you what is happening at scale.

A successful result for a message from billing@northstar.example could look conceptually like:

Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=bounce.mail.northstar.example;
 dkim=pass header.d=northstar.example;
 dmarc=pass header.from=northstar.example

The important part is not merely the word pass; it is the relationship between smtp.mailfrom, header.d, and header.from. With relaxed alignment, the bounce subdomain can align. With strict SPF alignment, it would need to match northstar.example exactly.

Common failures and how to fix them

“SPF passes but DMARC fails”

This means SPF authenticated a domain that does not align with the visible From domain, or DKIM did not provide an aligned pass. Configure a custom return-path or bounce domain under your domain, enable aligned DKIM, or change the From domain. Do not assume an SPF pass from a vendor-owned bounce domain satisfies DMARC.

“DKIM fails after a campaign is sent”

Check whether the sending platform actually signs the custom domain, whether the selector’s DNS record resolves publicly, and whether a gateway altered signed content. Also check that a long key was not truncated by the DNS provider. If a platform uses CNAME-based DKIM, verify the CNAME target exactly as supplied.

“Our SPF record has too many lookups”

Audit nested includes with an SPF checker. Remove inactive providers, avoid duplicate includes, and segregate mail streams by subdomain where that fits your architecture. Do not publish multiple SPF records or blindly replace a complex policy with -all; either can break legitimate mail.

“DMARC reports show an unknown sender”

Do not authorize it immediately. Correlate the IP, reverse DNS, count, and dates with internal owners and vendor accounts. High-volume unauthenticated sources may be spoofing attempts and are evidence that enforcement is valuable. Low-volume legitimate sources are often forgotten workflow tools that need custom domain authentication.

“We set p=reject and legitimate mail disappeared”

Revert only as far as necessary, then use reports and headers to identify the failed source. Typical causes are a new vendor, a delegated sender, a direct-to-MX application, a domain mismatch, or a marketing platform that was not configured with custom DKIM. Maintaining a change-management step for new sending tools prevents recurrence.

Sender requirements and deliverability implications

Large mailbox providers publish sender requirements that can differ by recipient, message volume, and whether a sender is categorized as bulk. Google and Yahoo, for example, publish requirements around authentication for bulk senders and other sending practices such as complaint handling and easy unsubscription. Treat their documentation as the authority for their own platforms, because thresholds and enforcement details can change.

Even for low-volume domains, authentication is worthwhile. A domain with a DMARC reject policy makes it materially harder for attackers to send a message that passes DMARC while impersonating that exact domain. It also creates a foundation for brand trust, incident investigation, and safer adoption of new email tools.

Authentication does not override content quality, sending reputation, list consent, complaint rates, message formatting, or recipient engagement. A fully authenticated sender can still land in spam. Conversely, a message can appear in an inbox despite imperfect authentication because each receiver makes its own risk decision. The goal is to establish verifiable identity, not to game a single deliverability score.

Tools and operating model for teams

Small organizations can begin with their DNS host, email-service documentation, raw-message headers, and a dedicated report mailbox. As volume and sender count increase, DMARC reporting platforms can normalize XML reports, identify sources, show alignment trends, and manage multiple domains. Examples include vendor platforms from DMARC-focused providers and email-security vendors; evaluate data retention, access controls, report processing location, integration needs, and pricing rather than choosing solely on a dashboard.

Assign clear ownership. Marketing may own campaign configuration, IT may own DNS, security may own DMARC policy, and product engineering may own transactional providers. One accountable program owner should maintain the sender inventory and approve new systems that use company domains.

A practical ongoing checklist is:

Review DMARC aggregate reports on a scheduled cadence.
Require custom SPF/DKIM and DMARC alignment before approving a new sending vendor.
Keep DKIM selectors and vendor DNS records documented.
Rotate or retire keys and selectors according to your provider’s supported process.
Monitor DNS changes, especially SPF edits and DKIM CNAME changes.
Test after platform migrations, domain acquisitions, marketing-agency changes, and email-routing changes.

Email authentication protocols: the rollout checklist

The safest sequence is inventory, authenticate, observe, enforce, and maintain. Starting with rejection before you understand your sender ecosystem can interrupt password-reset, invoice, and support mail; staying permanently in monitoring mode leaves your brand easier to spoof.

Use this final deployment sequence:

Inventory every system that sends with your domain in the visible From address.
Publish one valid SPF record and keep it within the lookup limit.
Enable aligned DKIM for every legitimate system.
Publish a DMARC p=none record with a protected aggregate-report destination.
Review real sending sources and fix all legitimate alignment failures.
Move through quarantine to reject at a pace supported by your evidence.
Continue monitoring and make authentication part of vendor procurement and email change management.

When those controls are in place, you can demonstrate success with DNS validation, message headers showing aligned DMARC passes, and DMARC aggregate reports showing authorized sources rather than unexplained traffic. That is the practical outcome email authentication protocols are designed to deliver: a domain identity receivers can verify and attackers cannot easily imitate.

FAQ

What are the main email authentication protocols?

The primary protocols are SPF, DKIM, and DMARC. SPF authorizes sending IP infrastructure, DKIM adds a verifiable signature, and DMARC requires aligned SPF or DKIM for the visible From domain and publishes a requested failure policy. ARC is a related protocol for preserving authentication context through intermediaries.

Do I need SPF, DKIM, and DMARC?

Yes. DMARC can pass through aligned SPF or aligned DKIM, but deploying both provides resilience and satisfies common mailbox-provider expectations. SPF alone does not protect the visible From address, and DKIM alone has no domain-owner enforcement policy.

What is the difference between SPF and DMARC?

SPF checks whether an IP may send for the envelope-sender domain. DMARC checks whether SPF or DKIM passed with a domain aligned to the visible From address, then applies the domain’s published policy request. SPF can pass while DMARC fails because the domains differ.

How long does DMARC implementation take?

DNS publication may take effect according to your DNS TTL, but safe enforcement takes as long as needed to identify and fix every legitimate sender. The appropriate timeline depends on the number of platforms, mail streams, and business cycles—not on a fixed number of days.

Does p=none protect my domain from spoofing?

No. p=none provides reporting and monitoring but does not request quarantine or rejection of failing mail. It is a discovery stage before moving to p=quarantine and, once legitimate sources are aligned, p=reject.

Email Authentication Protocols: A Practical SPF, DKIM, DMARC and ARC Guide