SPF, DKIM and DMARC are three DNS-based standards that let a receiving mail server check whether a message really comes from the domain it claims. SPF lists the servers that may send for your domain. DKIM adds a cryptographic signature that proves the message was not changed and that your domain approved it. DMARC ties those two checks to the visible From address and tells receivers what to do when a check fails.
For business email, these records matter. Since 2024, Google and Yahoo have required authentication from senders, and Microsoft Outlook.com followed in 2025. This guide explains each standard, how they interact, the mistakes that break delivery, the provider rules with their dates, and a rollout plan from monitoring to rejection. At the end we compare ways to host business email and show where our Mailcow add-on fits.
What SPF, DKIM and DMARC each do
SPF (RFC 7208)
The Sender Policy Framework lets a domain publish which hosts are authorised to send mail for it. The policy is a DNS TXT record that starts with v=spf1. A receiving server compares the connecting host with that list and gets a result such as pass, fail, or a permanent error. SPF alone does not check the From address that people see, which is why DMARC adds alignment.
DKIM (RFC 6376)
DomainKeys Identified Mail lets the owner of a signing domain take responsibility for a message. The sending server signs the message. The receiver fetches the public key from the signer's DNS and checks the signature. Because the signature is carried in the message, it can survive relays that do not change the content. A selector, set in the s= tag, lets a domain publish several keys at once, which makes key rotation possible.
DMARC (RFC 7489, replaced by RFC 9989)
Domain-based Message Authentication, Reporting and Conformance builds on SPF and DKIM. A DMARC pass needs an SPF pass or a DKIM pass whose domain aligns with the domain in the From header. The policy is a TXT record at _dmarc under your domain, with a policy of none, quarantine or reject, and an optional address for aggregate reports. Receivers may follow the policy but are not required to.
A note on the standard: RFC 7489 was published in 2015 as an Informational document. In May 2026 the IETF published RFC 9989 as a Proposed Standard. It obsoletes RFC 7489 and RFC 9091. The record still starts with v=DMARC1, so existing records keep working. RFC 9989 lists the removal of the pct tag and describes a t tag for testing, so check what your receivers and reporting tools support before relying on pct.
How SPF, DKIM and DMARC work together
| Standard | What it proves | Where it lives | Main weakness alone |
|---|---|---|---|
| SPF | The sending host is on the domain's approved list. | TXT record at the domain, starting with v=spf1. | Does not protect the visible From address by itself. Limited to 10 DNS lookups. |
| DKIM | The message was signed by a domain holding the key and was not changed in transit. | TXT record at selector._domainkey.example.com. | A valid signature can come from any domain. The domain must align with From for DMARC. |
| DMARC | At least one of SPF or DKIM passed and aligned with the From domain. | TXT record at _dmarc.example.com. | With p=none it only reports. It asks receivers to take no action. |
Alignment has two modes. Under relaxed alignment, the domains only need the same organisational domain. Under strict alignment, they must be identical. A DMARC pass shows that the domain owner authorised the use of the domain. It does not prove a message is safe. Google also notes that alignment is not needed for forwarded or mailing-list messages.
SPF DKIM DMARC example records for example.com
These examples show the shape of each record. They use the documentation domain example.com and an address from the documentation range 192.0.2.0/24. Replace them with your own values. Do not copy the key.
| Record | Name | Type | Example value |
|---|---|---|---|
| MX | example.com | MX | 10 mail.example.com. |
| SPF | example.com | TXT | v=spf1 mx ip4:192.0.2.25 -all |
| DKIM | s2611._domainkey.example.com | TXT | v=DKIM1; k=rsa; p=MIIBIjANBg...(public key shortened) |
| DMARC, monitoring | _dmarc.example.com | TXT | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com |
| Reverse DNS (PTR) | 25.2.0.192.in-addr.arpa | PTR | mail.example.com. |
The PTR record is set at the owner of the IP address, usually your server or network provider, not in your own zone. Mailcow's DNS guide shows a similar set of records and says the PTR must match the mail server's hostname.
Common mistakes with SPF, DKIM and DMARC
SPF: more than 10 DNS lookups
RFC 7208 limits the terms that cause DNS queries to 10 per evaluation. These are include, a, mx, ptr, exists and the redirect modifier. Going over the limit returns a permanent error, so SPF fails. The standard also says that more than two lookups that return nothing should give a permanent error. Every include of a third-party service counts, and the include itself may contain further includes. Count them before you add another sender. Replacing an include with a fixed address range removes a lookup, but then you must update the range yourself.
SPF: more than one record
A domain must not publish more than one SPF record. If a receiver finds more than one TXT record that begins with v=spf1, the result is a permanent error. When you add a service, merge it into the existing record. Also keep the record short: the standard advises staying under 512 octets so it fits one UDP answer, and a single TXT string is limited to 255 octets, so long records are split into several strings.
DKIM: weak or reused keys
RFC 6376 requires signers to use RSA keys of at least 1024 bits for long-lived keys. Google states that DKIM keys must be at least 1024 bits and recommends 2048 bits if your provider supports it. Yahoo also lists 1024 bits as the minimum. The standard advises against reusing a selector for a new key, so use a new selector for each rotation and remove the old one later. Do not delete the old key before the new one is signing, or outgoing mail goes out unsigned.
DMARC: staying at p=none
A policy of none is the right place to start, because it reports without affecting delivery. It is a poor place to stay. RFC 9989 describes none as expressing no handling preference, so it does not stop anyone from sending mail that pretends to be your domain. Google and Yahoo accept p=none as the minimum for bulk senders, but a monitoring-only policy gives you reports and little protection. Set a date to move on.
DMARC: no reports, and forgotten senders
Without an rua address you receive no aggregate reports, so you cannot see which systems send as your domain. Website forms, invoicing tools, newsletter services and support desks often send mail that fails alignment. Find them in the reports before you enforce.
Reverse DNS and TLS
Google and Yahoo both require valid forward and reverse DNS for sending servers. A self hosted mail server needs a PTR record that matches its hostname, and that record is set by whoever controls the IP address. Google also lists TLS for transmitting email as a requirement for all senders.
Sender requirements of Google, Yahoo and Microsoft
| Topic | Google (Gmail) | Yahoo | Microsoft (Outlook.com) |
|---|---|---|---|
| Applies to | All senders to personal Gmail accounts. Extra rules for senders of about 5,000 or more messages a day. Bulk status is permanent once reached. | All senders. Extra rules for bulk senders. The page we read does not define bulk. | Domains that send more than 5,000 emails a day to the consumer domains hotmail.com, live.com and outlook.com. |
| Dates | TLS added as a requirement in December 2023. Requirements effective 1 February 2024. Enforcement ramps up from November 2025. | Enforcement began in February 2024 and was rolled out gradually. | Enforcement date 5 May 2025. |
| SPF and DKIM | All senders: SPF or DKIM. Bulk senders: both. | All senders: SPF or DKIM. Bulk senders: both. | SPF and DKIM must pass. |
| DMARC | Bulk senders: a record with at least p=none. The From domain must align with the SPF or DKIM domain. | Bulk senders: at least p=none, DMARC must pass, rua is strongly recommended. | At least p=none, aligned with SPF or DKIM. Both aligned is preferred. |
| Reverse DNS | Valid forward and reverse DNS required. | Valid forward and reverse DNS required. A non-generic PTR is recommended. | Not listed in the Microsoft post we read. |
| Unsubscribe | Marketing and subscribed mail: one-click unsubscribe and a visible link. | One-click unsubscribe with a List-Unsubscribe header and a visible link. Unsubscribes honoured within 2 days. | Visible, working unsubscribe links are recommended. |
| Spam rate | Keep below 0.10%, never reach 0.30%. | Keep below 0.3%. | Not given as a figure in the post we read. |
| If you do not comply | Mail may go to spam or be rejected, for example with 5.7.26. Rejections can be temporary (4.7.x) or permanent (5.7.x). | The page we read does not describe the consequences. | Rejected with 550 5.7.515. An earlier plan to send such mail to Junk was replaced. |
Sources: Google email sender guidelines and FAQ, Yahoo Sender Hub best practices, Microsoft Outlook Tech Community post, read November 2026. Check the provider pages for the current wording.
If you send fewer than 5,000 messages a day, the bulk rules may not apply to you, but the base rules do. Google applies SPF or DKIM, reverse DNS and TLS to all senders. A business domain that sends invoices, quotes and newsletters from several systems can pass the volume line easily. Treating SPF, DKIM and DMARC as required for every domain is simpler.
SPF DKIM DMARC rollout: p=none, then quarantine, then reject
- List every system that sends mail as your domain: the mail server, the website, invoicing, newsletters, support tools and any scanner or printer.
- Publish one SPF record that covers them all, and count the lookups.
- Turn on DKIM signing in each system. Use 2048-bit keys where the system allows them.
- Wait before you publish DMARC. Google's rollout guide advises setting up SPF and DKIM at least 48 hours first.
- Publish DMARC with p=none and an rua address. Google's guide suggests at least one week of monitoring and reading the reports daily.
- Fix every legitimate sender that fails alignment. Add DKIM or SPF for it, or move it to a subdomain.
- Move to p=quarantine. Google's guide starts with a small percentage, 10 percent for a small organisation and 1 percent for a large one, and raises it gradually. Check that your reporting tool and receivers support pct, because RFC 9989 retires it.
- Move to p=reject when reports show no legitimate failures. Receivers then reject failing messages, which are never delivered.
- Keep reading reports. Re-check SPF and DKIM whenever you add a new sending service or change your mail provider.
The record for the monitoring step is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. For enforcement, change the policy to p=quarantine and later p=reject. Google's guide gives no fixed duration for the quarantine or reject phase, so decide by what the reports show.
Business email hosting: three ways to run it
For business email hosting, whatever you choose, SPF, DKIM, DMARC and reverse DNS must be correct. The choice changes who is responsible for the work and how much control you keep.
| Option | Who runs the servers | What you manage | Typical fit |
|---|---|---|---|
| Hosted suite, for example Exchange Online | The provider | Users, domain DNS records, policies. Exchange Online is listed at $4.00 (Plan 1) and $8.00 (Plan 2) per user per month, paid yearly, as of November 2026. | Teams that need Outlook, shared calendars and compliance tools, and prefer a per-user fee. |
| Hosted mailbox from a hosting or mail provider | The provider | Mailboxes and DNS records. The feature set depends on the provider. | Small teams that want simple mailboxes without running a server. |
| Self hosted mail server, for example Mailcow | You, or a service provider you hire | Everything above, plus updates, backups, monitoring and server security. | Teams with admin skills, data location needs, or many domains. |
A hosted suite gives the broadest feature set and puts the update work with the provider. A self-hosted server gives you control of the data location and the cost model, and in return you must run the checklist in our Mailcow security guide. A self hosted mail server also needs a clean IP address, a PTR record and a sending policy. If you want to compare products, see our comparison of Mailcow, Exchange and SmarterMail.
Where our Mailcow add-on fits
Our Managed Web Server does not include email. Email is a separate add-on that runs on a separate Mailcow server in Vilnius, Lithuania. It is priced by storage, in euros per month excluding VAT: 25 GB at €4, 50 GB at €7, 100 GB at €10, and each extra 100 GB at €10 more. Domains and mailboxes are unlimited, and mail domains are managed from the panel. Outbound mail is rate-limited and sent through relays.
For authentication, this has two practical consequences. First, because outbound mail goes through relays, ask us for the right SPF value for your domain before you publish it. Do not copy the example from a Mailcow guide without checking, since that example lists only your own MX and A records. Second, because outbound mail is rate-limited, check the limits before you plan large mailings, especially if you may fall under the bulk-sender rules above. For DKIM and DMARC, Mailcow's documentation says DKIM keys are generated in its web interface and published in DNS, and its DNS guide lists a DMARC record with a reject policy as an example. Use the monitoring policy first, as described above.
Where PFHW fits, and where it does not
The add-on fits agencies, freelancers and small businesses that host websites with us and want mail on separate infrastructure in the EU, where GDPR applies. It is a mail server add-on, not a bulk email or newsletter service. You publish the SPF, DKIM and DMARC records in whichever DNS service holds your zone.
- Webmail is the Mailcow server's, not part of the PFHW panel.
- There are no mailing lists. The importer reports cPanel mailing lists as not imported.
- Autoresponders, email filters and spam-filter settings are not in the PFHW portal and are not imported. Whatever Mailcow offers is on the mail server's own pages.
- Outbound mail is rate-limited and relayed, which affects large mailings.
Frequently asked questions
Do I need SPF, DKIM and DMARC for a small business?
Yes, in practice. Google and Yahoo require SPF or DKIM from all senders, and both require all three for bulk senders. Even a small domain gains from DMARC reports, which show who sends mail in your name.
What is the SPF 10 lookup limit?
RFC 7208 allows 10 DNS-querying terms in one SPF evaluation. These are include, a, mx, ptr, exists and redirect. If you exceed the limit, SPF returns a permanent error. Remove unused includes and keep one SPF record per domain.
Can I have two SPF records?
No. If a receiver finds more than one record that starts with v=spf1, the result is a permanent error. Merge all senders into a single record.
How long should I stay on p=none?
Google's rollout guide suggests at least one week of monitoring, then a move to quarantine when the reports show no problems. A longer period is reasonable if you have many senders. Do not leave p=none in place permanently, because it requests no action.
Is RFC 7489 still the DMARC standard?
No. RFC 9989, published in May 2026, obsoletes RFC 7489 and RFC 9091. The record format still starts with v=DMARC1, so existing records continue to work. Check your reporting tool for support of newer tags.
Does a self-hosted mail server need reverse DNS?
Yes. Google and Yahoo both require valid forward and reverse DNS for sending servers. The PTR record must match your mail server's hostname and is set by whoever controls the IP address.
Related resources
- Exchange alternative: Mailcow vs Exchange vs SmarterMail
- How Mailcow is secured, and what the operator must still do
- Why web and mail servers should be separate
- EU web hosting and GDPR
Sources
- RFC 7208, Sender Policy Framework, IETF
- RFC 6376, DomainKeys Identified Mail Signatures, IETF
- RFC 7489, DMARC, RFC Editor information page
- RFC 9989, DMARC, IETF Datatracker
- RFC 9989, DMARC, full text
- Google, Email sender guidelines
- Google, Email sender guidelines FAQ
- Google Workspace, Recommended DMARC rollout
- Yahoo Sender Hub, best practices and requirements
- Microsoft Tech Community, Outlook requirements for high-volume senders
- Microsoft, Exchange Online plans and pricing
- mailcow documentation, DNS records
- mailcow community forum, changing a DKIM key pair