You send an invoice. It never arrives. A week later you find out it was sitting in the customer's junk folder the whole time — and so, probably, were the three emails before it.
This is rarely about what you wrote. Modern mail providers decide whether to trust a message before they read a word of it, and the thing they check first is whether you can prove the mail is really from you. That proof is three DNS records: SPF, DKIM and DMARC.
What each record actually does
SPF is a list of the servers allowed to send mail using your domain. When a message arrives claiming to be from you, the receiving server looks up that list and checks whether the sender is on it.
DKIM adds a cryptographic signature to every message you send. It proves the message was not altered in transit, and — importantly — it survives forwarding, which SPF does not. If a recipient auto-forwards your mail to another address, SPF breaks and DKIM holds.
DMARC ties the two together and tells receiving servers what to do when a check fails: ignore it, quarantine it, or reject it outright. It also lets you receive reports about who is sending mail as your domain, which is how you find out someone is spoofing you.
Without them, you are an anonymous sender making claims about your identity. With them, you are a known sender. That difference decides the inbox.
How to check yours in about a minute
You do not need a tool for this. Send a message to any Gmail address, open it there, and choose Show original from the three-dot menu. The top of that page shows three lines:
SPF: PASS DKIM: PASS DMARC: PASS
All three should say PASS. If any says FAIL, SOFTFAIL, NEUTRAL or NONE, that is your problem and it is worth fixing before you change anything else about how you send mail.
The mistake that breaks working setups
The single most common way a functioning email setup gets destroyed is someone adding a second SPF record.
It happens with the best intentions. You sign up for a newsletter tool, or a CRM, or an invoicing system. It tells you to "add this SPF record to your DNS". You add it. Now your domain has two SPF records — and the specification allows exactly one. Mail servers seeing two do not merge them or pick the better one. They treat SPF as broken, and all of your mail starts failing, including the messages that were working perfectly an hour earlier.
The correct fix is to merge the new service into your existing record, not add another one. If you are not certain how to do that, ask whoever manages your DNS before you touch it.
When another service sends mail as you
This is the situation people miss. If a newsletter platform, CRM, helpdesk or website contact form sends mail as your domain, that service also has to be authorized — otherwise its messages fail authentication and go to spam even though your normal mail is fine.
The symptom is confusing and worth recognizing: your own emails arrive perfectly, but your marketing emails or automated notifications vanish. That is not a coincidence or a reputation problem. It is one authorized sender and one unauthorized one.
Everything passes and mail still goes to junk
Authentication proves a message is genuinely from you. It does not prove anyone wants it, and those are different problems.
If all three checks pass and messages still land in junk, the likely causes are the content itself, a sending reputation damaged by earlier spam from the domain — often from before you owned it — or the sending IP appearing on a blocklist. Those need investigating individually, starting with the full message headers.
Where OIS fits
When your domain and mail are with us, we configure SPF, DKIM and DMARC as part of provisioning. There is nothing for you to add and nothing to renew, and you should not need this article at all.
Two things are still worth telling us about: if you start sending through another service, so we can authorize it properly instead of you adding a second SPF record; and if your DNS is hosted somewhere else, because we can only manage records on domains whose DNS we control.
If mail is going to spam today, open a ticket with the Show original output and we will look at it. Do not start editing DNS records first — a partly-correct SPF record is worse than none at all.