Home › Blog › DMARC and Direct Send
Security · 17 October 2026 · 16 min read
The message came from the managing director’s address. Not a lookalike: the real domain, spelled correctly, asking finance to settle a supplier today. It was sent by someone who had never touched your tenant, from a server that has nothing to do with you, and it arrived because two settings that would have stopped it were left where Microsoft leaves them. This article explains the three email authentication records in plain terms, the two gaps, and how to close them without breaking your own invoicing.
Third in a series on how business email fraud works and what stops it. Earlier: invoice fraud through a hijacked thread and lookalike domains. Company names here are made up.
Spoofing is the oldest trick in email and still one of the most effective, because the protocol itself does not check who you are. A mail server can write any address it likes in the From line, the way anyone can write any name on the back of an envelope. Three DNS records were added over the years to let the receiving side check: SPF, DKIM and DMARC. Most Microsoft 365 tenants have the first, half have the second, and the third is usually present in a form that tells the world, politely, that you have decided not to enforce it.
That is gap one. Gap two is specific to Microsoft 365 and less known: a feature called Direct Send lets any machine on the internet deliver a message into your tenant with your own domain on it, unauthenticated, and your tenant treats it as internal. Both gaps are closed by configuration. Neither is closed by default.
What each record does, and what it does not
| Record | What it says | What it stops | What it misses |
|---|---|---|---|
| SPF | A list of the servers allowed to send mail for your domain. For Microsoft 365: include:spf.protection.outlook.com, plus your invoicing system, your CRM, your newsletter tool. | A stranger’s server claiming to be you, if the receiver checks and acts. | It checks the envelope sender, which the recipient never sees. The visible From line can still be yours. And it breaks when mail is forwarded. |
| DKIM | A cryptographic signature on each message, made with a private key only your servers hold; the public key is in DNS. In Microsoft 365, two CNAME records per domain, switched on per domain in the Defender portal. | Any alteration of the message in transit, and any message that was never signed by you. | It proves a message was signed by some domain. On its own it does not say that domain must match the From line. |
| DMARC | The policy that ties the other two to the From line the recipient sees (“alignment”), tells receivers what to do when neither passes (p=none, quarantine or reject), and asks them to send you reports of what they saw. | Spoofing of your exact domain, when the policy is reject and the receiver honours it. | Lookalike domains, which are a different domain entirely. And nothing at all while the policy is p=none. |
Microsoft 365 publishes SPF for you if you copy the record it gives you at setup. DKIM for a custom domain is not on until you enable it: until then, your mail is signed with the onmicrosoft.com initial domain, which does not align with your From address and does not help DMARC. DMARC is never created for you.
A DMARC record with p=none is a monitoring record. It asks receivers to report what they see and to take no action. It is the right first step, and most companies never take the second: three years later the record still says none, and every receiving server on the internet reads that as “deliver it anyway”. The spoofed message from the managing director fails SPF and DKIM at your client’s mail server, the server consults your policy, and your policy says to let it through.
The reason companies stall at none is a reasonable fear: that moving to reject will block their own mail. Invoices from the accounting system, quotes from the CRM, notifications from the ticketing tool, the newsletter platform, the scanner in the corridor. Some of those will indeed be sending as your domain without being in your SPF record or signed with your DKIM key, and the reports are how you find out which. That is what the next section is for.
The outside world has already moved. Since 2024, Google and Yahoo have required bulk senders to publish DMARC; since May 2025, Microsoft rejects mail to Outlook.com, Hotmail and Live addresses from any domain sending more than five thousand messages a day without SPF, DKIM and a DMARC record. A company that has not got its own records right is now losing mail as well as being impersonated.
p=none with a reporting address, if you have not already: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain. The reports are XML and arrive daily from every large receiver; nobody reads them raw. Use a DMARC reporting service, which turns them into a list of every source sending as your domain and whether each one passes.invoices.yourdomain) with its own records, or be replaced.p=quarantine; pct=10, then pct=50, then 100, a week or two each, watching the reports. Then p=reject. Add sp=reject so subdomains you never created cannot be used either, and give the same treatment to every domain you own but do not send from: v=spf1 -all, DMARC p=reject, and a null MX record, so a parked domain cannot be spoofed at all.The whole sequence takes six to ten weeks of elapsed time and a few hours of work. If your domain has recently moved tenants, read DKIM and DMARC after a tenant migration first; the keys do not move with the mailboxes.
Direct Send is a Microsoft 365 mail-flow path meant for printers, scanners and line-of-business applications that need to send notifications to your own users. The device connects to your tenant’s public mail endpoint, presents one of your domains as the sender, and delivers. No username, no password, no connector. It was designed for a scanner in your office. It works equally well for a server anywhere in the world, and the message it delivers is marked by your tenant as originating internally.
Whether that message then reaches the inbox depends on your own SPF, DKIM and DMARC, and on how your anti-spam policies treat mail that fails them from your own domain. Microsoft’s position is that with those records correctly set and enforced, Direct Send abuse is filtered. In practice we see tenants where the records are at p=none, where an “allow” rule was added years ago for the scanner that never got its SPF entry, or where internal mail is exempted from filtering altogether; in those tenants, the spoofed message from the managing director is delivered as if she had typed it.
In 2025 Microsoft added an organisation setting that switches the path off. It is off by default. Switching it on takes one line of PowerShell and about thirty minutes to take effect:
Set-OrganizationConfig -RejectDirectSend $true
From then on, a message arriving from outside with one of your domains as the envelope sender is refused unless it comes through an inbound connector you have configured, and the sender receives a bounce that reads:
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources
Before enabling it, find out what legitimate traffic uses the path:
Start-HistoricalSearch -ConnectorType NoConnector -Direction Received), or use the inbound messages report in the Exchange admin centre. Ninety days is available; look for the monthly jobs.Many tenants, when they look, find that nothing uses Direct Send at all. For them the change is one line.
Everything above protects your clients and suppliers from mail pretending to be you. Protecting your own staff from mail pretending to be their suppliers depends on the other half: whether your tenant acts on their DMARC policies. Since August 2023 Exchange Online applies the sender’s policy to messages its spoof intelligence identifies as spoofed, and the action is set in the anti-phishing policy. Set it to reject for p=reject senders and quarantine for p=quarantine, rather than the softer defaults; a rejection returns a bounce to the sending domain’s administrators, which is how misconfigured senders learn to fix their records. If a third-party filtering service sits in front of Microsoft 365, enable enhanced filtering for the connector, or the policy is evaluated against the service’s servers rather than the original sender and never fires.
Two further settings belong in the same policy: spoof intelligence, which is on by default and whose insight page shows which external senders are sending as your domains (the scanner you forgot about will be there); and the first contact safety tip, which banners the first message from any address. Neither needs a Defender licence. Impersonation protection, which handles lookalikes rather than spoofing, is in Defender for Office 365 Plan 1 and is covered in the previous article.
The records above are instructions to other people’s mail servers. Your own tenant also has a filtering stack that acts on spoofed mail, some of it in every plan and some in the Defender licences, and a set of tools for working out what happened once a message has got through. Both are worth knowing by name, because the question after an incident is always “why did this reach the inbox?”, and the answer is in these tools.
Microsoft 365 services that act on spoofed mail
| Service | What it does with a spoofed message | Where it is |
|---|---|---|
| Composite authentication | Exchange Online Protection runs SPF, DKIM and DMARC on every inbound message and then makes its own verdict, compauth, which also weighs sender reputation and history. A message that fails all three from a domain with p=reject is marked compauth=fail with a reason code, and the anti-phishing policy decides what happens to it. This is the layer that catches spoofing even when the spoofed domain has no DMARC record at all. | Every plan |
| Spoof intelligence | Learns which external senders legitimately send as your domains and as your partners’ (the newsletter platform, the ticketing tool, the scanner), lets you allow or block each one on its insight page, and treats the rest as spoofed. On by default. | Every plan |
| Anti-phishing policy: DMARC actions | The action for messages that fail the sender’s DMARC policy: reject, quarantine or deliver to Junk. Set reject for p=reject senders and quarantine for p=quarantine. | Every plan |
| Safety tips | The first contact tip, and the unauthenticated-sender tip that puts a question mark on the sender’s photo in Outlook when the message could not be authenticated. | Every plan |
| Zero-hour auto purge | Pulls a message back out of inboxes after delivery when Microsoft reclassifies it as phishing, which often happens within the hour as the same campaign hits other tenants. | Every plan |
| Safe Links and Safe Attachments | A spoofed message usually carries a link to a sign-in page or an attachment. Safe Links checks the link at the moment it is clicked, not when the message arrived; Safe Attachments opens the file in a sandbox first. | Defender for Office 365 Plan 1, inside Business Premium |
| Impersonation protection | For the lookalike and display-name variants of the same attack, covered in the previous article. | Defender for Office 365 Plan 1 |
| Priority account protection | Tighter filtering and separate reporting for the accounts most often spoofed and most often targeted: directors, finance. | Defender for Office 365 Plan 2 |
| Attack simulation training | Sends your own staff a spoofed message from “the managing director” and tells you who clicked, before an attacker does. | Defender for Office 365 Plan 2 |
The spoofed message in the opening paragraph gets past all of this in one of three ways: the tenant’s own DMARC policy is p=none, so there is nothing to enforce; an allow rule or a mail flow exception for “internal” mail bypasses filtering; or it came in through Direct Send and was never treated as external. Each is a configuration, and each is visible in the tools below.
A spoofed message that reached an inbox leaves a trail in four places. Work through them in this order; each answers one question.
Authentication-Results header: spf=, dkim=, dmarc= and compauth= with its reason code say exactly which checks failed and how the tenant decided. The X-Forefront-Antispam-Report header shows the spam and phishing verdicts and whether a rule or an allow entry overrode them. The Message header analyser in the Defender portal lays this out in plain language. Ten minutes here usually settles the “how did this get through?” question.EmailEvents table holds the authentication details, connector, sender IP address and delivery action for every message for thirty days, so a single query lists everything that arrived as your domain from outside, or everything that failed DMARC and was still delivered.For a business that wants this done for it, Microsoft 365 E5 adds the full set, including Microsoft Sentinel for alerting across the estate; for most companies under three hundred users, Business Premium with Defender for Office 365 Plan 2 as an add-on for the accounts that matter covers everything in this section.
Closing the two gaps needs no licence beyond Exchange Online. SPF, DKIM and DMARC are DNS records and a toggle in the portal; Reject Direct Send is an organisation setting; composite authentication, spoof intelligence, the DMARC-handling actions, zero-hour purge and the safety tips are in Exchange Online Protection, which every plan includes. Defender for Office 365 Plan 1, inside Business Premium, adds Safe Links, Safe Attachments and impersonation protection. Defender for Office 365 Plan 2 is what changes the investigation: Threat Explorer, advanced hunting, priority account protection and attack simulation turn the search for Direct Send traffic and the hunt for already-delivered spoofed mail into a matter of minutes rather than an afternoon, and let you remove a campaign from every inbox at once. A DMARC reporting service, from a few euros a month, is the one outside cost, and it pays for itself the first time it shows you a sender you did not know you had.
The spoofed message from the managing director did not defeat anything. It found a DMARC record that said none and a mail path that trusted anyone presenting your domain. Both are configuration, both are free to fix, and the fix for the first is also what the large mail providers now require before they will accept your mail at all.
The DMARC rollout described here, from reporting to reject in steps that never block your own invoices, the Direct Send inventory and the move of each device to an authenticated route, and the receiving-side policy that honours your suppliers’ records, are part of our incident response and hardening service. If the message has already been acted on, contact us for an initial incident assessment and response estimate.
No. SPF checks the envelope sender, which the recipient never sees, and it breaks when mail is forwarded. Without DMARC, a receiver has no instruction to compare SPF or DKIM with the visible From address, and without DKIM, forwarded mail fails. All three, with DMARC at reject, is the configuration that stops spoofing of your domain.
Only if something sends as your domain without being in SPF or signed with your DKIM key, which is exactly what the reporting phase finds. Four to six weeks at p=none with a reporting service, fix each source, then tighten in percentage steps. Done that way, nothing legitimate is blocked.
Not for your own domain. Until you enable it in the Defender portal and publish the two CNAME records, your mail is signed with the onmicrosoft.com domain, which does not align with your From address. Enable it for every custom domain, including ones you only use for aliases.
A path that lets devices and applications deliver mail to your own users as your domain without authenticating; it is also usable by anyone on the internet. Check the inbound no-connector report for legitimate use, move those senders to SMTP AUTH or a connector, then set RejectDirectSend to true. Many tenants find nothing uses it.
Read the Authentication-Results and X-Forefront-Antispam-Report headers on the original message: they show which of SPF, DKIM and DMARC failed, the tenant's composite verdict, and whether an allow rule overrode it. Then message trace for every recipient, and Threat Explorer in Defender for Office 365 Plan 2 to remove the delivered copies and see who clicked.
Yes, on the receiving side: enable enhanced filtering for the inbound connector, or Exchange Online evaluates SPF and DMARC against the filter's servers and never sees the real sender. On the sending side, make sure the filter's outbound servers are in your SPF record or sign with your DKIM key.