When your outgoing email lands in spam, the cause is almost always authentication: the SPF, DKIM and DMARC records on your domain that tell receiving mail servers your message is really from you. Correct records improve deliverability substantially, though nothing guarantees it; our Terms of Use say the same. The quick checks below find the usual culprit.
Quick checks
- Do the records exist at all? A domain sending mail with no SPF or DKIM is asking to be filtered.
- Is there exactly one SPF record? This is the classic silent killer. A domain can only have one SPF record, the TXT value that starts with v=spf1. Two of them fails permanently, and the symptom is exactly this: mail landing in spam days later while nothing in the zone looks wrong.
- Did anything change recently? A new email provider, a new marketing tool or a website move often adds or edits records. If spam problems started right after a change, that change is the suspect.
- Is it every recipient or one? One company filtering you is their policy. Everyone filtering you is your records.
Why you should not hand-edit these
SPF is a single line that has to name every service allowed to send for your domain. Merging a new service into it by hand, or letting a tool write a second record, is how domains break. Our DNS tooling treats your email records as protected: when it finds a second SPF record, it refuses to guess at a combination and routes the merge to our team instead. If you manage DNS elsewhere, apply the same caution, and leave MX, SPF, DKIM and DMARC alone when you are changing unrelated records.
The fix
For hosting and email customers, the correct records and how they fit together are covered in Email That Delivers: SPF, DKIM and DMARC. If your email runs through us and mail is being filtered, open a ticket at /portal/support with the recipient domain and roughly when it started, and we will check the records against what is actually sending.
Was this helpful?