Set up SPF for the actual envelope-sender domain, enable DKIM signing at every sending service, and publish a DMARC policy for the visible From domain. Then send real messages and check authentication and alignment at the recipient. A DNS lookup alone cannot validate the complete sending path.
Reviewed 16 October 2026. Corrected generic SPF include advice, lookup-limit wording, DKIM key reuse and rotation claims, and fixed DNS timing assumptions. The DMARC guidance reflects RFC 9989.
The Gmail and Yahoo sender requirements guide explains provider scope. Authentication helps recipients evaluate mail; it does not guarantee inbox placement or prove that the message is trustworthy.
Establish Access and Inventory Senders
Confirm who can edit the domain’s authoritative DNS and each sending service. Record the existing values before changing them. If access belongs to a former developer, use the website ownership transfer checklist.
List business mailboxes, marketing platforms, receipts, support systems and applications. For each, record the visible From domain, actual envelope/Return-Path domain, DKIM signing domain and provider setup instructions. Different services may use different subdomains.
If Cloudflare hosts the zone, the Cloudflare DNS guide covers record types and proxy settings. Allow time for configuration, DNS caches and representative mail testing; there is no universal 30-minute setup or propagation deadline.
What Each Mechanism Establishes
| Mechanism | What it checks | Important limit |
|---|---|---|
| SPF | Whether the connecting sender is authorized for the SMTP MAIL FROM domain, or HELO identity where applicable | It does not directly authenticate the visible From address; forwarding can affect the result |
| DKIM | A signature over selected headers and the signed body, associated with a signing domain | A valid signature does not establish that every header or the sender’s claims are trustworthy |
| DMARC | Whether a passing SPF or DKIM identity aligns with the visible From domain | Receivers apply local policy; legitimate indirect mail can fail alignment |
The protocol references are SPF, RFC 7208, DKIM, RFC 6376 and DMARC, RFC 9989. Provider requirements can require both SPF and DKIM to be configured even though an aligned pass from either can satisfy DMARC.
Step 1: Configure SPF for the Correct Hostname
Get the current values from each service. A provider may send using its own envelope domain or ask you to configure a custom Return-Path subdomain. Adding its include to your root domain does not automatically change either identity.
For example, Google’s documented SPF policy for a domain that sends only through Google Workspace is:
v=spf1 include:_spf.google.com ~all
This is conditional, not a record to copy into every domain. Follow Google’s SPF setup instructions and account for other legitimate senders. For other products, use their domain-specific instructions rather than assembling a generic list of every vendor’s include.
At the hostname being evaluated, maintain one TXT record beginning v=spf1. Multiple separate SPF policies cause a permanent error; unrelated verification TXT records may coexist. Validate the proposed record before replacing the existing one.
SPF limits evaluation to 10 DNS-lookup-causing terms, including nested evaluation of includes and redirects. This is not a limit of ten vendors or ten TXT records. ip4, ip6 and all do not consume that term budget. There are additional DNS-processing limits. RFC 7208, section 4.6.4.
~all returns softfail and -all returns fail for an otherwise unauthorized source. Neither guarantees a particular delivery outcome. Choose a complete policy with your mail administrator. Do not substitute a copied, static list of a provider’s IPs unless you can maintain it as that provider changes.
Save the TXT record at the correct hostname. DNS interfaces differ: some append the domain automatically and some expect a full name. Inspect the resulting authoritative answer to catch a duplicated suffix.
Step 2: Enable and Verify DKIM Signing
A sending service holds the private key; DNS publishes the corresponding public key, directly as TXT or through a provider-supplied CNAME. Publishing a key alone does not enable signing. Use the selector and domain from that service’s instructions.
Google Workspace
In the Admin console, open Apps → Google Workspace → Gmail → Authenticate email for the domain. Generate the DNS record, publish its complete value, then use Start authentication when it is visible. Send a test and inspect the result. Google DKIM setup.
Google recommends 2048-bit RSA DKIM keys where supported and requires at least 1024 bits for delivery to personal Gmail accounts. This is a Google receiving requirement, not a universal claim about every DKIM implementation. Google sender guidelines.
Microsoft 365
Open the domain’s DKIM settings in Microsoft Defender. Copy both CNAME hostnames and target values from the Publish CNAMEs details, publish them, then enable signing and test it. Newer and older custom domains can use different target formats; do not construct them from a generic tenant-name example. Microsoft DKIM instructions.
Postmark
In Sender Signatures, open the domain’s DNS settings. Publish the exact DKIM TXT hostname and value shown. A custom Return-Path uses a separate CNAME; it is not a second DKIM record. Verify the records in the product and inspect a delivered message. Postmark domain verification.
Self-Hosted Mail
Key generation is only one part of setup. Configure the signer, its protected key files, the mail server’s signing integration and the correct signing domain. Test the complete SMTP path using the documentation for the installed versions. Restarting a signer after pasting three configuration lines does not establish that Postfix or Exim is using it.
Use separate selectors when different services sign for the same domain. Choose a rotation schedule that fits the provider and your key-management policy; DKIM does not impose a universal annual rotation deadline. Retain an old public key long enough for already-signed mail and queued delivery to be verified. Coordinate removal using the service’s guidance rather than assuming exactly 48 hours is always sufficient.
Step 3: Publish and Review DMARC
Begin with an explicit record at _dmarc for the From domain you are reviewing:
v=DMARC1; p=none; rua=mailto:[email protected]
Example only: replace the reporting address with a working mailbox or configured reporting service. p=none requests monitoring rather than DMARC-specific quarantine or rejection. Recipients may still filter mail under their own rules. External reporting destinations can require DNS authorization.
Review reports and delivered messages across a representative business cycle. Correct legitimate senders and include forwarding, mailing lists and occasional jobs in the tests. Reports are not a complete record of every sent message or every recipient’s decision. Aggregate reporting is specified separately in RFC 9990.
Choose Policy Without Assuming Percentage Rollout
RFC 9989, published in May 2026, removes pct. A record containing pct=10 cannot promise that all receivers enforce policy on exactly 10% of messages.
Its optional t=y test flag lowers quarantine to none, or reject to quarantine, at supporting receivers. Older implementations may ignore the flag and apply p directly. It is not a safe universal replacement for sampling.
A controlled sending subdomain can help separate a mail stream, but its identity, policy inheritance and recipient behavior still need testing. Save the prior policy and a rollback owner before changing it.
Do not make p=reject an automatic final step: the current standard advises against it for general-purpose email domains because indirect mail can fail. Choose policy for the domain’s actual use and accepted delivery risks. RFC 9989, section 7.4.
Check Alignment
Compare the visible From domain with the authenticated SPF domain and DKIM d= domain. Relaxed alignment uses an organizational-domain relationship; strict alignment requires an exact domain match. A passing authentication result on an unrelated provider domain does not satisfy alignment for your From domain.
Validate Real Mail, Not Just DNS
For every production sending path:
- Confirm authoritative DNS answers and any cached result relevant to the test.
- Send to representative recipient providers.
- Inspect the receiver-added authentication results, envelope domain and DKIM signing domain. In Gmail, use Show original.
- Check alignment with the visible From address.
- For applicable marketing mail, test one-click unsubscribe through to suppression of later sends.
- Record the date, sending service, results, configuration owner and remaining exceptions.
A third-party mail-testing score is a diagnostic aid, not an inbox-placement guarantee or a compliance threshold. Avoid sending confidential test messages to a service you have not approved.
DNS cache behavior depends on existing TTLs, negative caching and provider processing. Lowering a TTL now does not invalidate an answer already cached under an earlier TTL. Cloudflare’s TTL explanation.
Common Mistakes
- Adding a second SPF policy instead of reviewing the existing one.
- Configuring SPF at the root when the sender actually uses a different envelope domain.
- Publishing DKIM DNS records without enabling signing.
- Copying a truncated public key or another tenant’s CNAME.
- Assuming SPF/DKIM pass means DMARC alignment passes.
- Treating a stricter DMARC policy as proof of better delivery.
- Removing an old DKIM key while delayed messages still need it.
Troubleshoot the Observed Failure
| Result | Investigation |
|---|---|
| SPF permanent error | Multiple policies, invalid syntax, lookup-term or other processing limits |
| SPF fail | Actual sending source and envelope identity; forwarding; legitimate sender configuration |
| DKIM failure | Actual selector and key, signer configuration, signed-content changes in transit and receiver details |
| DMARC failure | Whether any passing SPF or DKIM identity aligns; policy discovery and indirect delivery |
| Reports absent | Report availability, mailbox delivery, external-destination authorization and receiver participation |
Several causes can produce the same symptom. Use the full bounce or recipient result and the sending service’s logs before changing keys or policy.
Frequently Asked Questions
Can the same DKIM key be used for more than one domain? The protocol does not universally forbid it. Providers may impose their own arrangements, and separate keys can simplify isolation and independent rotation. Follow the actual service configuration instead of assuming reuse is impossible.
How long does setup take? It depends on the number of senders, account access, DNS caching and the testing required. Validate published results rather than waiting a fixed number of hours.
Does every subdomain need its own DMARC record? Not necessarily: policy discovery can use a parent policy. SPF and DKIM are evaluated for their actual identities. Record those identities before deciding which records to add.
What if authentication passes but delivery is poor? Investigate complaints, consent, list quality, content and recipient responses as well as authentication. Passing these checks does not guarantee inbox placement.
For the receiving providers’ current scope and requirements, return to the bulk sender overview. If you need help documenting the mail streams and testing changes, contact us.
