Email authentication with SPF, DKIM and DMARC helps receiving mail servers decide whether a message claiming to come from your domain is legitimate. They solve different parts of the authentication problem, so adding one DNS record is not the same as protecting every email your business sends. A useful rollout starts with an inventory, verifies real messages, and strengthens enforcement only after legitimate senders are accounted for.
This guide is for website owners and administrators who send support replies, password resets, newsletters, invoices, or transactional messages. It explains the relationships between the three standards without promising that authentication will eliminate phishing or guarantee inbox placement.
Email authentication: what each standard checks
SPF, or Sender Policy Framework, lets a domain publish which infrastructure is authorized to send mail for it. Receivers evaluate SPF using the envelope sender domain, not simply the address displayed in a user’s inbox. That distinction explains why a message can pass SPF while still presenting an unrelated visible From address.
DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to a message. The receiver retrieves the corresponding public key from DNS and verifies the signed material. The signing domain is identified by the signature’s d value. A valid signature establishes that the signed content verifies for that domain; it does not prove the message is useful or harmless.
DMARC evaluates alignment between the visible From domain and a domain authenticated by SPF or DKIM. A message can pass DMARC when at least one of those authentication methods passes and meets alignment requirements. DMARC also communicates a requested handling policy and supports reports that help domain owners observe delivery patterns.
Start with an inventory of every sender
List more than the mailbox provider. A website may send through a hosting server, an ecommerce service, a customer support platform, a newsletter tool, and an accounting application. Record the owner, sending domain, return-path behavior, DKIM configuration, and business purpose for each source.
Separate production systems from forgotten experiments. Ask whether each sender is still required and who can verify its configuration. Remove abandoned sources through the relevant service’s supported process rather than keeping indefinite DNS permissions because nobody remembers why they exist.
For a WordPress site, include password-reset mail and contact-form notifications in your tests. These workflows can fail quietly even while ordinary mailbox-to-mailbox messages continue working. Use controlled accounts and synthetic messages so the audit does not expose customer information.
Publish SPF without accumulating conflicting records
Use your provider’s documented SPF instructions and maintain one SPF policy record for the relevant domain. Creating multiple competing SPF records is not a safe way to authorize several services. Combine approved mechanisms deliberately and validate the resulting policy.
SPF has a limit on DNS-querying mechanisms and modifiers during evaluation. A policy that includes many third-party providers can exceed that limit even when the record looks short. Inspect nested includes with a trustworthy validator and avoid manually flattening provider addresses unless you have a maintenance process for their changes.
Do not copy a generic policy that authorizes infrastructure you do not use. If a provider supports a dedicated return-path subdomain, understand how that affects SPF and alignment before changing it. DNS syntax, provider configuration, and the actual message path must agree.
Enable DKIM and verify real signatures
Generate or enable DKIM through each sending service. Providers usually supply selector-specific DNS records; some use TXT records, while others delegate through CNAME records. Follow the instructions for your account and confirm that the expected record resolves publicly.
Send a real message from every approved workflow and inspect the receiving service’s authentication results. Check the signing domain and selector rather than stopping at a dashboard that says DKIM is enabled. A setting can be enabled while an application continues using a different sending route.
Plan key rotation with the provider. Removing an old selector too early may interfere with messages signed before the switch. Keep ownership and maintenance notes so a later migration does not leave obsolete records or break current senders.
Introduce DMARC in observation mode
A monitoring policy such as p=none can help collect evidence without requesting quarantine or rejection. It is a discovery stage, not an enforcement control. Set up a reporting destination you operate or an approved reporting service, and understand any authorization required for reports sent to another domain.
Aggregate reports summarize authentication activity. They can reveal unexpected senders, misalignment, and policy outcomes, but they are not a complete inventory of every delivered message. Receiver participation varies, and reports require interpretation rather than automatic approval of every observed source.
Review the reporting service’s access controls and retention. Even aggregated operational data deserves deliberate handling. Do not publish a personal mailbox as a reporting destination if the resulting volume and information exposure are inappropriate.
Test alignment before stronger enforcement
Compare the visible From domain with the envelope sender authenticated by SPF and the signing domain authenticated by DKIM. Relaxed and strict alignment behave differently. Choose a policy intentionally rather than enabling strict alignment merely because it sounds more secure.
Forwarding can disrupt SPF because the forwarding server changes the connecting infrastructure. DKIM may continue to pass if signed content is preserved, but message modification can break signatures. Test mailing lists, support forwarding, and other paths your organization actually uses.
After legitimate senders are aligned, consider a staged move toward quarantine and then rejection. Monitor business-critical mail during each change, document rollback, and coordinate with service owners. Receiving systems ultimately apply their own handling decisions, so enforcement is not an absolute delivery guarantee.
A practical verification checklist
- Confirm the SPF record is unique and evaluates within protocol limits.
- Verify DKIM signatures from every production sender.
- Check DMARC alignment in received message headers.
- Review reports for unauthorized or incorrectly configured sources.
- Test password resets, invoices, forwarding, and newsletters.
- Record the change owner and rollback procedure before enforcement.
Email authentication protects domain identity, not the whole account lifecycle. A compromised authorized mailbox can still send authenticated malicious messages. Continue using strong account authentication, narrow administrator access, and a recovery plan.
Frequently asked questions
Does DMARC stop all phishing?
No. It addresses unauthorized use of a protected domain under participating receivers’ policies. Attackers can still use lookalike domains, compromised legitimate accounts, misleading display names, and other techniques. Users need verification habits and reporting routes alongside technical controls.
Will these records guarantee inbox delivery?
No. Receivers also consider reputation, message content, recipient preferences, complaints, and sending behavior. Authentication is an important foundation, not a promise of placement in the primary inbox.
What should I do first?
Inventory your senders and inspect real messages before enforcing a restrictive policy. For the standards’ roles, consult Cloudflare’s SPF, DKIM and DMARC explanation. For adjacent DNS concepts, read our guide to DNS privacy and validation.
