The support ticket always reads the same way. A client says the phone has gone quiet, the analytics still show traffic, the form still shows a green confirmation message after submission, and a test from your own machine lands in your own inbox within four seconds. Nothing is broken in any way the site can tell you about. Then someone finally calls to ask why nobody answered the message they sent three weeks ago, and you go looking, and the mail server log shows a string that most site owners have never seen: 550 5.7.15.
That code is a rejection, issued by Microsoft, and it means the message was refused at the door rather than filed in a junk folder. It is the loudest symptom of a change that has been rolling through email for two years, and the reason so many small operators missed it is that the announcements were all written for bulk marketers.
Google's email sender guidelines split into two tiers, and only the second one carries a volume threshold. Senders of more than 5,000 messages a day to Gmail must publish SPF, DKIM and DMARC, align the From: header with one of them, and offer one-click unsubscribe on marketing mail. Everybody else, including the plumbing contractor whose site sends eleven form notifications a week, still has to set up SPF or DKIM, maintain valid forward and reverse DNS records for the sending IP, transmit over TLS, format messages to RFC 5322, and keep spam complaints below 0.3 percent. Those obligations took effect on February 1, 2024, and they have no floor.
The failure is almost always the From: header
Here is the specific thing that breaks, and it breaks on an enormous number of otherwise well-built sites. A contact form collects a visitor's name, message and email address, and then the form plugin puts that visitor's address into the From: header so replying feels natural. The message then leaves your web host's IP address claiming to come from a Gmail or Outlook domain that has never authorized your host to send anything.
Every check downstream fails at once. SPF asks whether that IP is permitted to send for gmail.com and gets a firm no. DKIM either finds no signature or finds one that does not match the domain in the From: line. DMARC, which exists to reconcile the two, sees a message wearing a domain it cannot vouch for and applies whatever policy that domain publishes. Gmail publishes a quarantine policy. Yahoo publishes a reject policy. The result is a notification that either lands in spam or never lands at all, and because the rejection happens between two servers, the visitor sees the same cheerful confirmation screen as always.
The fix takes about ten minutes and requires no new software. Send the message from an address on your own domain, something like forms at yourdomain, and put the visitor's address in Reply-To instead. The reply button still works exactly as the client expects, and the message is now making a claim your DNS can actually support.
Microsoft stopped filing and started refusing
On May 5, 2025, Outlook.com began enforcing SPF, DKIM and DMARC for senders of 5,000 or more messages a day to its consumer domains, and it chose a harsher remedy than Google did. Non-compliant mail is rejected outright rather than routed to junk. Microsoft explained the reasoning in its own announcement, documented by dmarcian: "After careful consideration and to ensure the protection of users and remove any confusion on why a message was in the junk folder for both the recipient and sender, we have made a decision to reject messages that don't pass the required authentication requirements."
Rejection is genuinely better than silent filing, because a bounce is a signal and a junk folder is a void. It also means that any shared hosting neighbor sending volume through the same IP block can drag your reputation into a category you never joined, which is the practical argument for routing transactional mail through a dedicated sending service rather than the mail function built into your host.
Four records, in order
Start with SPF, and keep it to one record
SPF is a single TXT record listing the servers permitted to send for your domain. The most common error is publishing two of them, which invalidates both, and the second most common is exceeding the ten DNS lookup limit by chaining include statements for every service that has ever sent on your behalf. Audit the list against services you currently use, remove the rest, and end the record with a hard fail rather than a soft one once you are confident it is complete.
DKIM is what actually survives forwarding
SPF breaks the moment a message is forwarded, because the forwarding server is not on your list. DKIM signs the message itself with a private key and publishes the public half in DNS, so the signature travels intact. Most reputable sending platforms generate the keys and hand you the records to paste. Use a key length of 2048 bits, and rotate the selector when you change providers rather than leaving stale keys published indefinitely.
DMARC starts at none and should not stay there
A DMARC record at p=none satisfies the letter of both Google's and Microsoft's bulk requirements while enforcing nothing, which makes it a monitoring tool rather than a protection. Point the aggregate report address at a mailbox you will actually read, spend two or three weeks confirming that every legitimate sender passes, then move to quarantine and eventually to reject. Domains that publish reject are the ones spoofers give up on, and the reports are the only way to discover that your invoicing platform has been failing alignment since March.
Reverse DNS is the one people forget
Google's baseline requirement for all senders includes a valid PTR record matching the sending IP, and this is exactly the setting a small operator cannot fix from inside a control panel. It belongs to whoever owns the IP address, which means a support ticket to the host. If the host will not set it, that is useful information about the host, and it belongs in the same conversation as everything else covered in our look at what infrastructure obligations now come standard.
Test the way the receiving server sees it
Sending yourself a message proves almost nothing, because your own mail client trusts your own domain and will happily render a message that a stranger's server would refuse. Send instead to a fresh address at Gmail, one at Outlook.com and one at Yahoo, then open the raw headers and read the authentication-results line. It states pass or fail for SPF, DKIM and DMARC in plain language, and it is the only verdict that matters.
Register the domain in Google Postmaster Tools while you are there. It reports the spam rate that the 0.3 percent threshold refers to, and without it you are guessing at the one number Google explicitly told you to watch. When Google announced the framework on October 3, 2023, Gmail security and trust group product manager Neil Kumaran framed the goal as removing that guesswork from the sender's side: "You shouldn't need to worry about the intricacies of email security standards, but you should be able to confidently rely on an email's source." Two years later, the intricacies did not go away, they simply moved into DNS, where a site owner can fix them once and stop thinking about them.
Put it on the maintenance checklist, not the emergency list
The reason email authentication keeps surfacing as a crisis is that it produces no visible failure until a client counts missing leads. Add the three DNS records to whatever you already run through when you take over a site, alongside the backup check and the plugin audit, and add a quarterly review of the DMARC aggregate reports for anything sending on the domain. It costs ten minutes and it removes an entire category of the calls that end up in a full emergency triage.
