This was not written by an email admin. Start with the real basics:
Your MTA should announce itself and DNS should agree. So your MTA says: HELO smtp.example.co.uk
smtp.example.co.uk will resolve to an A record (say a.b.c.d) and a reverse lookup will also work:
d.c.b.a.in-addr.arpa PTR smtp.example.co.uk.
Remember this is all about reputation, so if you also DNSSEC sign example.co.uk, then you will look like you care about your domain reputation.
Then do SPF, DKIM and DMARC. Note how the example for SPF stops at ~all and not -all. The rest is also superficial.
Anyway, I run email systems that do the job properly and it is not trivial and certainly not formulaic. There is no shortcut to getting an IP address/range trusted.
The advice on that page is ... good as far as it goes but woefully inadequate for running an email system. It's a good start.
I’ve never seen evidence that DNSSEC helps email reputation. Always willing to consider new evidence though.
Reputation, in my experience, is not really based on tech stuff. You can ruin it with bad technical configuration, sure. But the only way to grow it above average is to send a steady stream of emails that readers open and click, sustained over a period of time, with no complaints.
If you hosted your own email server, why would you need to be familiar with SES, especially if you've been hosting longer than SES providers have been around?
Like email, I run my own HTTP server, serving directly to clients. I know about Cloudflare just from HN threads, but have never used it or know much about that whole reverse proxy universe beyond the very low-level details from having written several reverse proxies myself.
Why would they? I’ve been running Internet servers (web, DNS, SMTP, IMAP, database) for about 25 years and until recently have only had the roughest idea of what EC2 or an S3 buckets are. It’s only because my employer recently started working with a new company that uses AWS that I’d have heard of SES. Also, I’ve no idea what the Azure equivalents are. If I ever need to know, I’ll find out but until then, ignorance is bliss.
I recently tried bouncing mail during the header phase when DMARC didn't align, but it rejected more legit emails than SPAM. Most of the junk we've been getting passes DMARC and has an unsubscribe link.
> Most of the junk we've been getting passes DMARC and has an unsubscribe link.
You say that like its a problem.. its a formidable solution!
Has worked for me for many years now: Just fail2ban-style block (groups of) relays that attempt to send an unsubscribe-link destined for a mailbox that never ever subscribes to anything. Those malicious-compliance folks add these unsubscribe links everywhere because they determined that its a cheap method for reducing blocks. That makes them reliably stand out whenever they hit strictly human-to-human mailboxes that simply never have any reason to "unsubscribe". Its like a honeypot, and all it took was a strict policy about what a tiny fraction of mailboxes can and cannot be used for.
I'll have to ponder the method you describe. I know I could implement that on my own mailboxes and some automated endpoints, but not sure how that would work for other users on our domain.
Your suitable mailboxes will be very distinguishable by grepping for past triggers per original/unexpanded recipient. Most older destinations would have thousands of non-spam hits, the suitable ones will have 0-3 with an obvious quick fix. For me it was department-level to-whom-it-may-concern aliases: All the mailing lists and web service signups use the appropriate department/employee name, yet much of the incoming mail sent by humans - and: much of the mailing-list-impostors - comes through one of the aliases that merely clarify the topic/location but end up in the same boxes anyway.
DMARC doesn't really do much to prevent general spam. It prevents spoofing the from address, which provides some protection against phishing, but if the email is from the domain it claims to be, it can pass DMARC whether or not it is spam.
We generally run on Microsoft 365 and use SendGrid for transactional emails such as password resets.
Main domain has SPF set up correctly as per MS docs.
We have the CNAME set up for a like em1234 sub-domain as per SendGrid’s docs which their docs say should cover SPF even if the emails we send have a from address of our main domain (eg noreply@example.com), this is apparently because receiving servers are supposed to do SPF checks against the replyTo address which sendgrid does populate with an address on the subdomain.
This has worked fine for years, Gmail for example is happy and looking at mails from us says everything passes.
However, we recently onboarded a large corporate whose server was blocking the SendGrid emails because it was checking the SPF against the from header rather than the replyTo.
Only way to let the email through was to either add SendGrid SPF records to our main domain, or change the from address of the SendGrid emails, neither of which was 100% ideal.
Not going to try tell the client they’ve configured their server wrong, but have they?
Edit: for those unfamiliar with the intricacies of SMTP, the first three lines sent are HELO, MAIL FROM:, and RCPT TO:. The From: address that you see in your mail client is actually another header that gets sent once the server provisionally accepts the message based on the first three headers. It's the difference between the return address on the envelope of a paper letter, and an address printed on the letterhead of the actual letter.
No, they haven’t. With your current config sounds like you are failing SPF alignment. Is your SPF record in strict mode? Do you have DMARC set up and are you DKIM signing the SendGrid emails from your domain?
This was not written by an email admin. Start with the real basics:
Your MTA should announce itself and DNS should agree. So your MTA says: HELO smtp.example.co.uk
smtp.example.co.uk will resolve to an A record (say a.b.c.d) and a reverse lookup will also work:
d.c.b.a.in-addr.arpa PTR smtp.example.co.uk.
Remember this is all about reputation, so if you also DNSSEC sign example.co.uk, then you will look like you care about your domain reputation.
Then do SPF, DKIM and DMARC. Note how the example for SPF stops at ~all and not -all. The rest is also superficial.
Anyway, I run email systems that do the job properly and it is not trivial and certainly not formulaic. There is no shortcut to getting an IP address/range trusted.
The advice on that page is ... good as far as it goes but woefully inadequate for running an email system. It's a good start.
I’ve never seen evidence that DNSSEC helps email reputation. Always willing to consider new evidence though.
Reputation, in my experience, is not really based on tech stuff. You can ruin it with bad technical configuration, sure. But the only way to grow it above average is to send a steady stream of emails that readers open and click, sustained over a period of time, with no complaints.
They don’t do ips they just use SES, same as resend and a bunch of other email startups lately
Sorry, what is SES?
Simple Email Service, by AWS. Mainly tramsactional email, but noy exclusively
Wait, you claim to run email systems and don't know what SES is?
If you hosted your own email server, why would you need to be familiar with SES, especially if you've been hosting longer than SES providers have been around?
Like email, I run my own HTTP server, serving directly to clients. I know about Cloudflare just from HN threads, but have never used it or know much about that whole reverse proxy universe beyond the very low-level details from having written several reverse proxies myself.
Why would they? I’ve been running Internet servers (web, DNS, SMTP, IMAP, database) for about 25 years and until recently have only had the roughest idea of what EC2 or an S3 buckets are. It’s only because my employer recently started working with a new company that uses AWS that I’d have heard of SES. Also, I’ve no idea what the Azure equivalents are. If I ever need to know, I’ll find out but until then, ignorance is bliss.
Precisely those who run their own email systems have no need to know what SES is.
I think a better resource is http://www.open-spf.org/
This looks like a pretty good resource.
I'd like to add the following, which I continually reference and has led to repeatable success:
https://www.linuxbabe.com/mail-server/setting-up-dkim-and-sp...
And as far as confirming it works, I continually rely on sending to a gmail address.
Under the three dots is "view original" which gives you
SPF, DKIM, and DMARC results.
(edit:formatting)
This is a cool site to visualise your SPF, DKIM, DMARC setup interactively.
https://www.learndmarc.com/
+1. I used this to set up DMARC and ended up signing up for their service. Only like ~$12/year and works.
https://www.pangram.com/history/8c0a7f5f-3db7-4435-b459-04ae...
Don’t waste your time.
Is the information actually wrong, misleading, or otherwise deficient?
Idk but I’m not wasting my time checking all that. Feel free to give us a detailed line by line analysis of what’s misleading/deficient.
The reason for my comment is that we, the readers, are most likely gonna spend more time reading this post than the author(s) did writing it.
Thanks for the heads up, looks like this is a case of AI;DR (maybe I should get some bumper stickers printed).
It clearly is AI generated but the ideas as presented are mostly sound.
However, it is woefully incomplete.
I recently tried bouncing mail during the header phase when DMARC didn't align, but it rejected more legit emails than SPAM. Most of the junk we've been getting passes DMARC and has an unsubscribe link.
> Most of the junk we've been getting passes DMARC and has an unsubscribe link.
You say that like its a problem.. its a formidable solution!
Has worked for me for many years now: Just fail2ban-style block (groups of) relays that attempt to send an unsubscribe-link destined for a mailbox that never ever subscribes to anything. Those malicious-compliance folks add these unsubscribe links everywhere because they determined that its a cheap method for reducing blocks. That makes them reliably stand out whenever they hit strictly human-to-human mailboxes that simply never have any reason to "unsubscribe". Its like a honeypot, and all it took was a strict policy about what a tiny fraction of mailboxes can and cannot be used for.
I'll have to ponder the method you describe. I know I could implement that on my own mailboxes and some automated endpoints, but not sure how that would work for other users on our domain.
Your suitable mailboxes will be very distinguishable by grepping for past triggers per original/unexpanded recipient. Most older destinations would have thousands of non-spam hits, the suitable ones will have 0-3 with an obvious quick fix. For me it was department-level to-whom-it-may-concern aliases: All the mailing lists and web service signups use the appropriate department/employee name, yet much of the incoming mail sent by humans - and: much of the mailing-list-impostors - comes through one of the aliases that merely clarify the topic/location but end up in the same boxes anyway.
DMARC doesn't really do much to prevent general spam. It prevents spoofing the from address, which provides some protection against phishing, but if the email is from the domain it claims to be, it can pass DMARC whether or not it is spam.
Indeed. Ultimately we're still relying on blacklists, Bayesian filters, and hueristics to detect actual SPAM.
[dead]
You also need to set up reverse dns to avoid ending up in spam folders at the big ones.
We generally run on Microsoft 365 and use SendGrid for transactional emails such as password resets.
Main domain has SPF set up correctly as per MS docs.
We have the CNAME set up for a like em1234 sub-domain as per SendGrid’s docs which their docs say should cover SPF even if the emails we send have a from address of our main domain (eg noreply@example.com), this is apparently because receiving servers are supposed to do SPF checks against the replyTo address which sendgrid does populate with an address on the subdomain.
This has worked fine for years, Gmail for example is happy and looking at mails from us says everything passes.
However, we recently onboarded a large corporate whose server was blocking the SendGrid emails because it was checking the SPF against the from header rather than the replyTo.
Only way to let the email through was to either add SendGrid SPF records to our main domain, or change the from address of the SendGrid emails, neither of which was 100% ideal.
Not going to try tell the client they’ve configured their server wrong, but have they?
SPF doesn't check the reply-to address, only that the host sending the mail is allowed to send mail for the domain in the MAIL FROM: header.
See: http://www.open-spf.org/FAQ/What_it_does/
Edit: for those unfamiliar with the intricacies of SMTP, the first three lines sent are HELO, MAIL FROM:, and RCPT TO:. The From: address that you see in your mail client is actually another header that gets sent once the server provisionally accepts the message based on the first three headers. It's the difference between the return address on the envelope of a paper letter, and an address printed on the letterhead of the actual letter.
No, they haven’t. With your current config sounds like you are failing SPF alignment. Is your SPF record in strict mode? Do you have DMARC set up and are you DKIM signing the SendGrid emails from your domain?
[flagged]
This is an aws ses wrapper so is basically irrelevant in the email world