Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To set up SPF, DKIM and DMARC, first identify every service that sends mail for your domain, then configure SPF and DKIM using each provider’s exact DNS instructions. Publish DMARC in monitoring mode, review aggregate reports and test real mail flows before moving to quarantine or reject. SPF or DKIM passing on its own is not enough: at least one must pass with a domain aligned to the visible From address.
What SPF, DKIM and DMARC each do
These mechanisms check different things. SPF authorizes sending infrastructure for an SPF identity; DKIM lets a sending system sign a message with a domain-linked cryptographic signature; DMARC checks whether a passing SPF or DKIM identity aligns with the domain in the visible From header. DMARC also lets a domain owner publish a requested handling policy for messages that fail and request reports.
| Mechanism | What it checks | Where configuration lives | Role in DMARC |
|---|---|---|---|
| SPF | Whether sending infrastructure is authorized for an SPF identity | Domain DNS TXT record | A passing SPF result counts only if its MAIL FROM domain aligns with the visible From domain |
| DKIM | Whether a message has a valid cryptographic signature associated with a signing domain | Sending system and public key in DNS under a selector | A passing signature counts only if its signing domain aligns with the visible From domain |
| DMARC | Whether a passing SPF or DKIM identity aligns with the visible From domain | DNS TXT record at _dmarc | Publishes the domain owner’s requested failure handling and can request reports |
Relaxed alignment permits identifiers that share an organizational domain; strict alignment requires an exact domain match. RFC 9989 notes that relaxed alignment has been sufficient in practice for nearly all domain owners. DMARC validates domain use under these mechanisms; it does not verify the local part of an email address or certify that a message’s content is safe, truthful or wanted. A DMARC pass also does not guarantee inbox placement.
The current DMARC specification is RFC 9989, which supersedes RFCs 7489 and 9091. The related specifications are RFC 7208 for SPF, RFC 6376 for DKIM and RFC 9990 for DMARC aggregate reporting.
#1 Best Overall
Before changing DNS, inventory every sender
List every legitimate service that sends messages using your domain, not just employee mailboxes. Include your mailbox provider, website or application, marketing and support platforms, invoicing service and any other third-party sender. Check each service’s current instructions for the precise DNS record, selector and sending domain it requires.
- Record which From domain each service uses.
- Find out whether it supports SPF, DKIM, or both, and whether it can sign with a domain aligned to your From domain.
- Check the domain’s existing DNS records before editing them; other systems may already depend on them.
Google’s Email sender guidelines say all senders must use SPF or DKIM and bulk senders must use SPF, DKIM and DMARC. Google recommends all three for sending domains. These are Google’s requirements and guidance, not a universal description of every receiver’s rules; provider policies can change. Google also warns that omitting a third-party sender from SPF makes its messages more likely to be marked as spam.
Rank #2
Publish or correct SPF
Use your DNS host’s interface and the exact SPF mechanisms authorized by your mail providers. Do not copy a generic SPF string: the correct value depends on which services send for your domain. Check whether an SPF policy already exists before adding or editing a TXT record. A domain must have one valid SPF policy, not separate competing policies for different senders. Keep within SPF’s evaluation constraints, and consult RFC 7208 and your providers’ documentation for details.
SPF authenticates the evaluated SPF identity, not automatically the visible From address. For DMARC, the relevant SPF identifier is the MAIL FROM domain; it must align with the visible From domain for an SPF pass to count toward DMARC.
Enable DKIM for each sending platform
- In each service’s mail or domain-authentication settings, request its DKIM configuration.
- Copy the selector and public-key DNS record exactly as supplied. Publish it at the requested DNS name; the selector name and record value are provider-specific.
- Return to the service and enable DKIM signing if the provider requires a separate activation step.
- Send a test message through that service and inspect its authentication results to confirm the DKIM signature verifies.
A valid DKIM signature is not enough for DMARC if the signing domain does not align with the visible From domain. If a provider offers a custom signing domain, follow its instructions to configure one that aligns. Google’s guidance for personal Gmail delivery calls for DKIM keys of at least 1024 bits and recommends 2048-bit keys when supported; treat that as Google’s guidance, not a universal key-size rule.
Publish DMARC in monitoring mode
DMARC is a TXT record published at the _dmarc name for the domain. For example, a record for example.com is published at _dmarc.example.com. Begin with a monitoring policy such as p=none and configure an aggregate-report destination your organization can receive and process. Use the exact syntax and destination requirements in the current standard and your DNS provider’s documentation; do not treat a sample record as universal.
Rank #4
p=none requests monitoring rather than enforcement. Aggregate reports show messages claiming to use your domain and summarize authentication outcomes and sending sources. RFC 9989 says, “Proper consumption and analysis of DMARC aggregate reports is essential to the success of a DMARC deployment.” If reports arrive as XML that is impractical to review manually, use a suitable internal workflow or a report-processing service; a paid service is not required to publish DNS authentication records.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteReview reports and test real mail flows
Allow reports and test messages to reveal how your domain is actually used. Confirm that every expected sender appears, that its SPF or DKIM result passes, and that at least one passing identifier aligns with the visible From domain. Reports may uncover legitimate systems that were missing from your inventory.
- Investigate unexpected sources before treating them as unauthorized; identify the service or owner first.
- Check forwarding and mailing-list flows, which can affect authentication results.
- For each failure, determine whether the sender is legitimate, whether its DNS setup is correct and whether its authenticated domain aligns.
- Test ordinary messages from every important sending service, including application-generated mail, rather than relying on a single mailbox test.
Receiver behavior and delivery outcomes are not guaranteed by the presence of a DMARC record. Reports and message tests are evidence for deciding whether your own legitimate streams are ready for a stricter policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Move to enforcement only when the evidence supports it
After legitimate mail is accounted for and reports show stable authentication and alignment, consider changing the DMARC policy to quarantine and later to reject if appropriate. Make changes deliberately and continue monitoring after each change. A stricter policy can affect legitimate messages if a sender was missed or configured incorrectly; do not move to enforcement merely because SPF and DKIM records exist.
Google says its DMARC policy requirement can be set to none, but other receivers may apply different rules. Follow the requirements of the mail providers and services relevant to your domain, and verify their current documentation before relying on a policy setting.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Common setup mistakes to avoid
- Adding a second SPF policy: inspect and update the existing policy rather than publishing multiple SPF records for one domain.
- Assuming any SPF or DKIM pass satisfies DMARC: the passing identifier must also align with the visible From domain.
- Forgetting non-mailbox senders: websites, apps and third-party platforms can send as your domain and need the appropriate provider configuration.
- Publishing DKIM but not enabling signing: complete any activation step in the sending platform and verify a test message.
- Going straight to reject: monitor reports and investigate legitimate failures before enforcing a policy.
- Treating authentication as a content safety check: DMARC does not establish whether a message is benign or desirable.
For DNS-specific workflows, Cloudflare’s email security records documentation, last updated May 5, 2026, describes SPF, DKIM and DMARC configuration and its DMARC Management workflow. Regardless of DNS host, use the authoritative instructions from your email services for the actual record values.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
