Activity Messenger Help Center
Advisory: Outlook email delivery and DMARC
Published November 9, 2026.
If your organization sends email from its own domain, check its authentication records when messages to Outlook, Hotmail, Live or MSN addresses bounce. This can affect communications such as confirmations, invoices and newsletters.
What has been reported?
In a November 6 report, MailRoute describes intermittent rejections beginning November 5 for domains without DMARC, including smaller senders. The reported error is:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
This is a provider report, not a Microsoft announcement of a new requirement for every sender. A successful delivery to one recipient does not establish that other messages were accepted.
Microsoft's published requirements
Microsoft's Outlook sender announcement describes authentication requirements for high-volume domains, with enforcement beginning May 5, 2025. Microsoft requires SPF and DKIM to pass, a DMARC policy of at least p=none, and alignment through SPF or DKIM. Its 550 5.7.515 troubleshooting guide explains the requirements and provides a DMARC example.
What to check in Activity Messenger
- Open the affected send-out and inspect the recipient's result using message tracking. Follow Troubleshoot undelivered messages to distinguish a bounce from missing open tracking or spam filtering.
- Confirm the actual From address. The Reply-to address controls replies; changing it does not authenticate the From domain.
- Follow Send email from your own domain to verify the domain and sender addresses. Copy the DNS records shown for your domain exactly, including DKIM CNAME records. Do not substitute a generic SPF record.
- Have the administrator who manages your domain's DNS check DMARC separately. Access to Activity Messenger alone does not grant permission to edit DNS.
Check DMARC in Activity Messenger
Once your domain has been added in your organization's From email settings, step 3 of that page offers a Check DMARC button. It reads your domain's public DNS without changing anything, then shows the DMARC record it found and what to do next:
- No DMARC record found: ask your DNS administrator to add the TXT record displayed. It is the minimal record described below.
p=none: no change is needed.p=quarantineorp=reject: keep this policy if your senders pass DMARC, and confirm that step 1 of the page shows your domain as verified.- Invalid record or several records: ask your DNS administrator to correct the existing record, or to keep only one.
- The check could not be completed: DNS did not answer. Try again in a few minutes.
If your domain has no DMARC record of its own, the check reports the record inherited from its parent domain when there is one.
Add DMARC if it is missing
For a From address such as info@example.com, the DNS administrator can check the TXT record at _dmarc.example.com. A minimal starting record is:
| DNS setting | Example |
|---|---|
| Type | TXT |
| Name | _dmarc.example.com (some providers require only _dmarc) |
| Value | v=DMARC1; p=none |
Check whether the DNS console appends the domain automatically. Review an existing policy before editing it: do not add a duplicate DMARC record or replace a working stricter policy with this example.
The Amazon SES DMARC guide recommends starting with monitoring, then progressing toward enforcement after legitimate senders are aligned. p=none requests no DMARC enforcement; it does not make failing messages pass. Receiving systems can still filter or reject mail.
The minimal example does not request aggregate reports. Reporting needs a rua destination configured by your DNS administrator. A record alone is insufficient: DMARC needs a passing SPF or DKIM result aligned with the visible From domain.
After the DNS change
Allow time for DNS changes to become visible, then send a test to an address you control and inspect its authentication results. Review the affected recipients before retrying messages.
Keep recipient addresses current, respect unsubscribe choices and monitor delivery failures. See Amazon SES sender-reputation best practices. Authentication helps establish sender identity; it does not guarantee inbox placement.