If you run mail on your own VPS, watch this one carefully. In early November 2026, administrators started reporting that Outlook.com was bouncing messages from domains that publish no DMARC record at all - not because the mail was spammy, but because the sender’s domain simply had no DMARC entry in DNS.[9] The messages failed with a permanent rejection in the SMTP conversation, not a junk-folder move. Your mail either arrives or it disappears, and figuring out why takes an afternoon of DNS archaeology.

The fix is not hard. You need three DNS records - SPF, DKIM, and DMARC - published correctly, and one alignment rule that most people get wrong. This guide walks through all of it against primary sources: the RFCs that define each record, Microsoft’s published sender requirements, and the official docs of the common self-hosted stacks (Postfix, docker-mailserver, mailcow). No guesswork, no “best guesses.”

The short version

Add a DMARC record to your domain. If you send from a self-hosted server, that means four records total:

  • v=spf1 mx -all (or similar) at the domain root - SPF
  • v=DKIM1; k=rsa; p=... at selector._domainkey - DKIM
  • v=DMARC1; p=none; rua=mailto:... at _dmarc - DMARC
  • A PTR (reverse DNS) record at your IP’s provider that points back to your mail server hostname[1]

The DMARC record is the one that ties the other two together and tells receivers what to do with failures. Until it exists, Outlook.com has been treating mail from your domain as unauthenticated, and per community reports in early November 2026 it started rejecting part of that mail outright.[9]

What actually changed, and what did not

Be precise here, because the distinction matters for how you react.

What is officially documented by Microsoft: Since May 5, 2025, Microsoft requires domains sending more than 5,000 messages per day to Outlook.com accounts to fully pass SPF, DKIM, and DMARC. Mail from non-compliant high-volume senders is sent to the Junk Email folder, and if the issue is not resolved, the sending domain can be rejected with the error 550; 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.[1] This is a published, official policy, and it is aimed at bulk senders.

What the community started seeing in November 2026: Administrators reported a new rejection - 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records - hitting domains that had no DMARC record, even low-volume senders sending a handful of messages a day.[9] This behavior was not, as of the day this article was written, formally announced in Microsoft’s published postmaster or policy documentation.[1] So treat it as what it is: a widely reported trend and an early signal, not a quoted line from Microsoft’s spec. The safe move is identical either way - publish all three records and make sure DMARC passes with alignment.

The reason this is worth your time even if your mail is low-volume: the “reject” behavior is the pattern every major provider has followed - first mandatory for bulk senders, then quietly expanding to everyone without a DMARC record.[9] A working DMARC policy also protects your domain from being impersonated, and it is the only record that lets receivers report back to you about who is forging your mail.

Why your mail worked for years and now seems to stop

Email authentication is three separate mechanisms, and none of them alone tells a receiver “this domain is real.” Together they do. Here is what each one actually does, from the standards that define them.

SPF (RFC 7208) lets the domain publish a list of IPs that are authorized to send mail for it.[3] The receiver looks up the SPF record for the envelope sender’s domain and checks whether the connecting server’s IP is on the list. It answers: “is this server allowed to send for this domain?” It says nothing about the From address shown in your mail client.

DKIM (RFC 6376) is a digital signature over the message. The sending server signs outgoing mail with a private key, and the receiver verifies the signature against a public key published in DNS under a selector._domainkey name.[4] It answers: “was the body and headers of this message signed by the holder of a known private key?”

DMARC (RFC 7489) is the policy on top, and it is the part you are missing. DMARC tells the receiver how it should treat messages that fail authentication, and it requires that whichever method passes - SPF or DKIM - aligns with the domain in the visible From address.[5] That alignment is the step people skip, and it is why a domain can have perfect SPF and DKIM but still fail DMARC.

If your server has been sending mail for years with functioning SPF and DKIM, your mail did pass authentication. But without a DMARC record, Microsoft’s policy documentation has treated those message as not fully authenticated, which is the gap behind the November rejections.[1][9]

Step 1: Publish an SPF record

The SPF record is a TXT record at the domain root. It lists every IP and every authorized service that sends mail for your domain. For a single self-hosted mail server, this is the common form:[6]

MYDOMAIN.TLD.  IN  TXT  "v=spf1 mx -all"

The mx mechanism authorizes whichever hosts serve your MX record. If your mail server also has a static public IP that is not the MX host, use ip4:

MYDOMAIN.TLD.  IN  TXT  "v=spf1 ip4:203.0.113.7 -all"

The tail matters. ~all is a softfail (receiver should treat unlisted senders as suspicious but usually not reject); -all is a hard fail (receiver can reject). Microsoft’s postmaster guidance requires SPF to pass for the sending domain.[1] For a self-hosted server where you control every sender, start with -all once you are sure no third-party service sends mail using your domain’s envelope address - otherwise that service will silently break.[6]

One hard rule: SPF has a limit of 10 DNS lookups per mechanisms chain in the original design, so do not keep appending include: entries from every marketing tool you have ever tried. Each include can consume lookups, and a record that exceeds the limit causes a permerror that fails the check entirely.[3]

Step 2: Set up DKIM

DKIM requires a key pair. The private key stays on your mail server and signs outgoing mail; the public key goes into DNS so receivers can verify the signature.

If you run docker-mailserver, generate the key with the bundled setup script. The current default is RSA-2048, which the project explicitly recommends over larger keys for compatibility:[7]

docker exec -it <container-name> setup config dkim

The script writes a DNS record file (by default mail.txt) containing the public key. Publish it as a TXT record under the matching selector name - default mail._domainkey, i.e. mail._domainkey.MYDOMAIN.TLD with content like:[7]

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

With mailcow, the web UI generates the DKIM public key for each domain and shows you the exact TXT record to add; the shared hosting docs list the record at dkim._domainkey for the newer stack and mail._domainkey for others.[6]

After you publish it, restart or reproduce your mail server so it picks up the key, then send a test and inspect the signed headers. DKIM only works when the signature covers the From header domain - which overlaps directly with the alignment we will set up next.[7]

Step 3: Add the DMARC record - the one you were missing

DMARC is a single TXT record at _dmarc. This is the record whose absence triggered the November rejections.[9] Start in monitoring mode, p=none:

_dmarc.MYDOMAIN.TLD.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@mydomain.tld"

The parts, from the DMARC standard and Microsoft’s setup doc:[2][5]

  • v=DMARC1 - the version tag, required.
  • p= - the policy for failed mail: none (monitor only), quarantine (send failures to spam), or reject (ask receivers to drop failures). Microsoft’s sender guidance recommends at least p=none, with p=reject preferred.[1]
  • rua= - the address that receives aggregate DMARC reports, letting you see which legitimate sources are failing.

Use p=none first, collect reports for a week or two, and only tighten to quarantine then reject once you are sure all your legitimate senders pass with alignment. Microsoft explicitly routes outbound mail from domains whose own DMARC policy is p=reject or p=quarantine through a high-risk delivery pool if it fails DMARC - so a strict policy on a broken setup makes your deliverability worse, not better.[2]

The alignment rule that most people get wrong

Here is the part that separates “I added three records” from “it actually passes.” DMARC requires more than SPF or DKIM passing on their own. The passing method must also align with the domain in the user-visible From address.[2][5]

There are two alignment modes for each mechanism, and you can set them independently with the aspf and adkim tags:

  • Relaxed (default) - the SPF or DKIM domain must share the same organizational domain (the registrable part after the public suffix) as the From address. So DKIM signed with d=m.mail.mydomain.tld aligns with From user@mydomain.tld, because both sit under mydomain.tld.
  • Strict - the contacting domain must match the From domain exactly, character for character (after the aspf=[r|s] / adkim=[r|s] tag semantics in RFC 7489).[5]

In practice this is why a self-hosted server can pass SPF and DKIM yet still fail DMARC: if your web forms or third-party relays send with an envelope or signing domain that is not your From domain, the check fails alignment. DKIM must be signed with d= equal to your From domain (or its subdomain under relaxed rules), and your SPF must cover the actual connecting server for the From domain.

A typical monitoring policy that explicitly sets relaxed alignment and asks for reports:[2]

_dmarc.MYDOMAIN.TLD.  IN  TXT  "v=DMARC1; p=none; aspf=r; adkim=r; pct=100; rua=mailto:dmarc@mydomain.tld; ruf=mailto:dmarc@mydomain.tld"

pct=100 applies the policy to all messages; lower it only while trialing. ruf is the URI for forensic failure reports (optional). This record says: “monitor everything, relaxed alignment on both, and send me the reports.”

Verify everything with dig

Do not trust the DNS panel’s “status green” - check from the outside. These three commands, run from a machine that is not your mail server, confirm each record resolves and looks right.

Check SPF (domain root) and DMARC (_dmarc) and DKIM (your selector):

dig +short TXT mydomain.tld
dig +short TXT _dmarc.mydomain.tld
dig +short TXT mail._domainkey.mydomain.tld

You are looking for: an SPF record starting "v=spf1, a DMARC record starting "v=DMARC1; p=, and a DKIM record containing "v=DKIM1; k=rsa; p=.... If dig returns nothing for _dmarc, that is exactly the state the November rejections targeted.[9]

Also confirm reverse DNS. Microsoft requires a valid PTR record that matches your sending hostname, and mail from IPs in dynamic ranges may be refused entirely.[1] The PTR is set at your IP provider, not your DNS registrar:

dig +short -x 203.0.113.7

The result should be the FQDN (for example mail.mydomain.tld) that your mail server announces in its HELO/EHLO greeting.

Then send a real test message to an Outlook.com / Hotmail / Live address and inspect the message headers. In the headers you want the Authentication-Results lines to show spf=pass, dkim=pass, and dmarc=pass (p=NONE) with the right alignments. If any shows fail or bestguesspass, fix that record before you trust the setup.

A word on PTR and IP reputation you cannot skip

DNS records are necessary but not sufficient. Even with perfect SPF, DKIM, and DMARC, your mail can still bounce if the sending IP has poor reputation or sits in dynamic space. Microsoft’s postmaster page is explicit: connections from dynamic IP ranges may not be accepted, and mail servers must have valid reverse DNS.[1] So spend the two minutes to set the PTR correctly - it is invisible in your DNS zone but fully visible to every receiver.

For a fresh VPS IP, warm-up still applies: start low-volume, keep your sending consistent, and watch the DMARC reports for legitimate sources failing so you can fold them into SPF/DKIM before you tighten the policy.

The bottom line

The November 2026 rejections are a sharp reminder that email authentication is no longer optional for self-hosted mail. The fix is three DNS records and one correctness rule:

  1. SPF at the root listing every authorized sender - v=spf1 mx -all for a typical server.[1][3]
  2. DKIM under your selector - generate the key, publish the public key TXT, sign with d= matching your From domain.[4][7]
  3. DMARC at _dmarc in monitoring mode with rua=, then tighten to quarantine/reject after you have confirmed alignment passes.[2][5]

Run dig to confirm all three resolve, set the PTR, send a test message to an @outlook.com account, and read the Authentication-Results header. Once dmarc=pass shows against your real From domain, your domain is no longer the easy target Microsoft has been quietly rejecting - and you have also closed the door on spoofers using your domain in their phishing.

Sources

  1. Microsoft - Outlook.com Postmaster: Policies, Practices, and Guidelines (high-volume sender requirements since May 5, 2025; SPF must pass; DMARC at least p=none; PTR and dynamic-IP requirements). https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies - checked 2026-11-09
  2. Microsoft Learn - Set up DMARC to validate email (DMARC TXT record syntax, p=none/quarantine/reject, high-risk delivery pool, alignment). https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dmarc-configure - checked 2026-11-09
  3. RFC 7208 - Sender Policy Framework (SPF): https://datatracker.ietf.org/doc/html/rfc7208 - checked 2026-11-09
  4. RFC 6376 - DomainKeys Identified Mail (DKIM): https://datatracker.ietf.org/doc/html/rfc6376 - checked 2026-11-09
  5. RFC 7489 - DMARC: Domain-based Message Authentication, Reporting, and Conformance (alignment, aspf/adkim relaxed vs strict, pct, rua/ruf). https://datatracker.ietf.org/doc/html/rfc7489 - checked 2026-11-09
  6. mailcow: dockerized documentation - DNS setup (SPF, DKIM, DMARC records, PTR). https://docs.mailcow.email/getstarted/prerequisite-dns/ - checked 2026-11-09
  7. docker-mailserver - DKIM, DMARC & SPF (key generation, RSA-2048 default, DNS record names). https://docker-mailserver.github.io/docker-mailserver/latest/config/best-practices/dkim_dmarc_spf/ - checked 2026-11-09
  8. Microsoft TechCommunity - Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders (defender blog post behind the 5.7.515 policy). https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 - checked 2026-11-09
  9. MailRoute blog - “Outlook.com Is Quietly Rejecting Email From Domains Without DMARC” (community/admin reports of 550 5.7.1 “Message lacks SPF/DKIM/DMARC Auth Records” hitting low-volume, no-DMARC domains since early Nov 2026). Trend signal, not a primary fact source. https://mailroute.net/blog/outlook-rejecting-email-without-dmarc - checked 2026-11-09