Improve Email Deliverability: PTR, SPF, DKIM and DMARC Basics

Improve Email Deliverability: PTR, SPF, DKIM and DMARC Basics

Originally published 1 October 2020 · Reviewed 5 November 2026

Email deliverability is whether your messages reach the inbox instead of the spam folder or nowhere at all. Part of it depends on reputation and content, but a large and fixable part depends on four DNS-based controls: reverse DNS, SPF, DKIM and DMARC. This guide explains each in plain terms, how they apply in Microsoft 365, and what the big mailbox providers expect from senders now. It replaces our earlier post on this subject, which focused on marketing mail.

Reverse DNS (PTR)

A reverse DNS record maps an IP address back to a host name. If you operate your own mail server, receiving servers commonly check that the sending IP has a PTR record, and that it matches the name the server uses to introduce itself. A missing or mismatched record is a classic reason for mail being refused or filtered. You usually set the PTR record with the company that provides the IP address, such as your internet or hosting provider, not in your own DNS zone.

If you send through Microsoft 365 or a mail provider, they manage the sending IPs and reverse DNS for you, so this control matters mainly for self-hosted servers, appliances and scanners that send directly.

SPF

Sender Policy Framework lets a domain publish a list of systems allowed to send mail for it, in a TXT record that starts with v=spf1. A receiving server compares the sending IP address with the list. Practical rules:

• Publish only one SPF record per domain. Two records cause a permanent error.
• List every legitimate sender, by IP address or by an include: for each service such as Microsoft 365 or your newsletter platform.
• Respect the 10 DNS lookup limit. Each include, a, mx and similar mechanism can count, and exceeding the limit makes SPF fail. Remove services you no longer use.
• End with an all mechanism. ~all (soft fail) is common while you are testing; -all (hard fail) is stricter once you are sure the list is complete.

DKIM

DomainKeys Identified Mail signs outgoing messages with a private key, and the receiver verifies the signature using a public key published in your DNS. It proves that the message was authorised by the domain and was not altered in transit. Each sending service signs with its own selector.

In Microsoft 365, DKIM signing is on for the default onmicrosoft.com domain, and for a custom domain you publish two CNAME records for the selectors and then enable signing in the Microsoft Defender portal. Do the same for every third-party service that sends as your domain. Rotate keys when the provider recommends it.

DMARC

DMARC tells receivers what to do when SPF and DKIM do not align with the visible From domain, and where to send reports. Begin with a record such as p=none and a reporting address, read the reports to discover every system that sends as your domain, fix those that fail, then move to p=quarantine and finally p=reject. Our rollout plan covers the stages, and the lookup tool checks the result.

DMARC also protects your brand from spoofing, which improves your reputation indirectly. Attackers who cannot spoof you do not generate complaints that attach to your name.

What the large providers expect

Gmail and Yahoo introduced requirements for bulk senders in 2024, and Microsoft's consumer mail service, Outlook.com, announced similar requirements in 2025. In outline they ask high-volume senders to authenticate with SPF and DKIM, publish DMARC, keep spam complaint rates low, and make unsubscribing easy for marketing messages. The thresholds and dates differ between providers and have been updated, so read each provider's current sender guidelines. Even low-volume senders benefit from meeting the same standard.

Beyond DNS

• List hygiene. Remove bounced and inactive addresses, and do not buy lists.
• Consent and unsubscribe. Send to people who asked, and make leaving easy.
• Consistent sending. Sudden jumps in volume look like abuse. Warm up new domains and addresses.
• Content. Avoid misleading subjects, hidden text and link shorteners that hide destinations.
• Separate streams. Keep transactional mail on a different subdomain from marketing mail so a problem in one does not damage the other.
• Monitor. Use DMARC reports, bounce messages and the providers' postmaster tools.

A checklist

1. Every sending system is inventoried.
2. Self-hosted senders have matching PTR records.
3. One SPF record exists, under the lookup limit.
4. DKIM signing is enabled for each sender.
5. DMARC is published, with reports reviewed.
6. Policy is moving from none to quarantine to reject.
7. Complaint and bounce rates are monitored.
8. Unsubscribe and consent processes work.

Diagnosing a delivery problem

When mail goes missing, start from the evidence. Read the bounce message for the status code and the receiving server's explanation, because a 5.7.x code usually points at authentication or reputation. Check the message headers of a delivered test for SPF, DKIM and DMARC results. Run your domain through a lookup tool to see the records as the world sees them, and compare them with what you think you published. Then look at what changed recently: a new sending service, a DNS edit, a new mail gateway, or a rise in volume. Fix one thing at a time and send another test.

Microsoft references

• Set up SPF to identify valid email sources for your Microsoft 365 domain, reviewed 5 November 2026.
• Use DKIM for email in your custom domain, reviewed 5 November 2026.
• Use DMARC to validate email, reviewed 5 November 2026.

This article was first published on 1 October 2020. It was rewritten on 5 November 2026 in new words with current provider expectations, and it also replaces the short SPF troubleshooting post. Check each provider's live guidance, which takes precedence.