I'm trying to set up a Return-path for Mandrill emails. This is what I currently have:
From: hello#info.example.com
Return-path: bounce-mc.us3_25014995.932533-27c52c08ee#mail52.suw11.mcdlv.net
and I'm wondering how to set up the Return-path header. Would it pass the SPF alignment if the Return-path would be the following:
From: hello#info.example.com
Return-path: hello#bounce.example.com
?
I've found this: https://mxtoolbox.com/dmarc/spf/spf-alignment which mentions couple of examples about SPF alignment but I can't find anywhere in the SPF standard whether if I have subdomains both in the From & Return-path if that'd align just based on top of the top-level example.com domain.
I'm unfortunately not able to set up the Return-path to match the From like so:
From: hello#info.example.com
Return-path: hello#info.example.com
As I can't create a CNAME record for info.example.com as I already have an MX record for this subdomain to route incoming emails to Gsuite (see this issue: https://support.google.com/a/forum/AAAA034zvV85E_AluPsqD8/?hl=en&gpf=%23!msg%2FApps%2F5E_AluPsqD8%2F0x_O1tqmAwAJ&msgid=0x_O1tqmAwAJ)
As a sender, you don't set a return path. That's the job of the receiving server. As RFC5321 says:
A message-originating SMTP system SHOULD NOT send a message that
already contains a Return-path header field. SMTP servers performing
a relay function MUST NOT inspect the message data, and especially
not to the extent needed to determine if Return-path header fields
are present. SMTP servers making final delivery MAY remove Return-
path header fields before adding their own.
The envelope sender is what's used in the MAIL FROM SMTP command, and that's what SPF checks. SPF does not look at what's in the from address header – one of its weaknesses – but fortunately exactly what DMARC is designed to (ahem) address. That MX Toolbox article is misleading because it categorises this alignment as an SPF feature when it's a DMARC one, which is why you're not finding it in the SPF spec.
If mandrill is expected to handle your bounces while maintaining DMARC (relaxed) alignment, I would expect your envelope sender to be something like:
bounce-mc.us3_25014995.932533-27c52c08ee#mandrill.example.com
and then you'd have a CNAME in your domain's DNS pointing it at mandrill:
mandrill CNAME mail52.suw11.mcdlv.net
Related
I tried to find the answer from google but all result is showing why SPF is important instead of explain the working mechanism and how mail server(gmail, microsoft, smartermail, etc) implement it, generally.
Below is the criteria in came out but could find the answer:
SPF record exist, labeled sender & mail server domain aren't same, mail server domain/IP included
SPF record exist, labeled sender & mail server domain aren't same, mail server domain/IP not included
SPF record exist, labeled sender & mail server domain are same, mail server domain/IP not included
SPF record not exist, labeled sender & mail server domain aren't same
SPF record not exist, labeled sender & mail server domain are same
I would like to know, generally, which criteria will mark as junk mail by mail server.
Thank you.
Edit 1:
Lets put the other factor apart, how mail server decide to increase/decrease the level of "points" by looking at SPF only?
SPF is only responsible for identifying sources of email, and has no opinion about content.
You're asking how receiving email servers decide what to do with messages that fail SPF checks. That's a good question, because it's something that a domain owner should be concerned about, and historically this has been undefined (as others have pointed out), and so varied wildly. Fortunately there's now a mechanism whereby the domain owner can say what a receiving server should do with messages that fail SPF checks: DMARC.
DMARC includes a p parameter that tells a receiver what to do with messages that fail checks. Its value can be none (do nothing, or whatever the receiver chooses), quarantine (put in spam or similar), or reject (bounce the message).
DMARC can apply these same policies to DKIM, and it also provides additional validation of the alignment between the SMTP envelope sender and the From message header.
If a domain lacks a DMARC record, you're back to guessing the outcome, and subject to the whims of receiving mail server admins' decisions.
v=spf1 include:spf.falconide.com include:sendgrid.net include:_spf.google.com ip4:xx.xxx.xxx.x ~all
Above is my SPF record for my domain, I am using an external tool to get open-source threat intelligence, in the tool it says my SPF config is not secure. Support is unavailable at the moment.
Does anything look insecure about the config?
No, this looks ok. The only thing I would change is to put the ip4 mechanism first.
You don’t provide any specifics of the actual error report, but it would not surprise me if it is misreporting thé ~all as a problem, even though it’s very unlikely to be. We would need to see your DMARC config to tell.
Maybe it just doesn't want you to use the soft fail?
If possible, try changing ~all to -all
Check the fail policy and qualifiers items of SPF records in Wikipedia:
https://en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding
https://en.wikipedia.org/wiki/Sender_Policy_Framework#Qualifiers
Use softfail (~all) as hardfail is NOT at all reliably enforced and can act in unexpected and seemingly random ways (suddenly a hosting company or mailbox provider stops or starts honoring hardfails).
Only a few mailbox providers reject based on just an SPF hard fail, and that's a moving target. For this reason, ~ALL is a best practice.
It’s DMARC that more reliably rejects if you want to tell mailbox providers to reject mail that fails DMARC. To to pass DMARC, either SPF or DKIM must fail and the domains in alignment. In. relaxed mode (by far the most common), alignment means the same organizational domain so example.com aligns with foo.example.com.
Always start with a p=none, a reporting only policy in DMARC and only VERY cautiously ramp up to a more aggressive DMARC policy such as p=reject or p=quarantine, as they can break legit mail if there’s legit mail that fails DMARC.
Delay deploying a more aggressive DMARC policy until you're sure all your legit mail's accounted for and authenticated. That way, only mail that's not authorized by you or flat out domain spoofing email (spammers and phishers) will fail DMARC.
Also, note that many ESPs by default have you use your own donain as the header from and use a domain of their own as the Envelope From.
If you request and setup a custom mail from domain, you can often get a subdomain of your domain set up the Envelope FROM (example.example.com) and the header from example.com (that recipients actually see).
If your envelope from isn’t example.com itself but instead foo.example.com then having the SPF set in your organizational domain uses as the header from won’t be useful. SFP is useful in the envelope from not the header FROM.
DKIM is signed by the header from domain (usually your organizational domain, example.com) and SPF is relevant in the envelope FROM domain only (e.g.,foo.example.com).
Also, keep in mind that an SPF record only allows 10 DNS lookups to be valid so check with a couple validation tools to makes sure it’s 10 or under. The above SPF you set uses 6/10 DNS lookups and is valid.
The SPF you have in your organizational domain isn't going to help, unless your Envelope From Domain is example.com.
And again ~ALL isn’t a problem. You can confirm this by doing some web searches on the risks and benefits of setting a softfail vs. a hardfail in SPF.
Some ESPs use their own domain as the envelope from meaning you need to explicitly work with your ESP to configure foo.example.com as the envelope from to get domain alignment with example.com, your organizational domain, and DKIM signing domain.
A complication is that many ESPs use a domain of there own for your Envelope From Domain and offer services/features such as a "custom sending domain," enabling you to use a subdomain of your own domain as the Envelope From Domain. Given that alignment policies have recently become more strict, it's a good idea to use a subdomain of your own domain as the Envelope From Domain rather than an ESP domain. For example, Microsoft recently enacted a policy whereby domain mis-alignment by itself causing either SPF or DKIM to fail is in itself enough to route email to spam. Other mailbox providers have been moving toward this sort of measure to try to get a handle on domain spoofing and the phishing and spamming that comes along with it.
Envelope FROM domain: Recipients do not see this domain.
Header FROM domain: Recipients can see this in the visible FROM line.
i'm wondering: after we received a boss-scam mail that was showing the faked From in the webinterface, i read a bit about how SPF is checked, and apparently it is checked against the Return-path and not the From header. (This reddit was good summary https://www.reddit.com/r/sysadmin/comments/20rnt6/smtp_question_does_spf_only_validate_the/ )
Whats the benefit of this? As far as i can see, this renders the whole idea almost useless, as it doesnt prevent spammers from sending spam with faked From headers at all. What am i missing here?
(This is just because i'm wondering, i'am aware that DKIM + DMARC will solve this spam problem :) )
SPF validates the envelope sender (AKA SMTP MAIL FROM, Return-Path,Bounce Address henceforth sender). it's purpose is to deny the use of forged senders, by disallowing the sender to be used from unauthorized servers. stopping the generation of mail with forged senders (where SPF is supported)
BATV, (and other types of VERP) can be used to reject backscatter from those systems that do not check SPF and reject forged senders.
SRS (another type of VERP) is required if you do a mailing list - you can't retain the original sender because the list server will (most likely) not be included in the originators SPF
DKIM is the one that deals with email headers. it allows you to cryptographically sign selected email headers and full or partial content (but don't do partial signatures on MIME Multipart-Alternative messages - that will end badly)
Don't try to make SPF responsible for something it's not. SPF simply lists which servers can send mail for your domain. It checks the envelope sender (MAIL FROM) at the SMTP level, which is the value that ends up in the return-path header, but only after it's passed SPF checks. What you're saying is that (assuming you have a strict SPF policy) you're allowing someone to send fake mail from one of your own mail servers, which is a problem much further up the chain than the From header, and one that would not be solved by DKIM. Perhaps your SPF record is not strict enough? We can't tell from the information you posted.
I'm having trouble understanding why SPF breaks forwarding.
Say my mail is me#domain.com, and I'm send an email to joe#mit.edu.
Assume that Joe configured his mit.edu account to forward mail to his personal account, joe#gmail.com.
Now I would expect the SMTP conversion between my domain's MTA and mit.edu's MTA to look something like that:
220 mit.edu.ac.il
HELO domain.com
250 OK
MAIL FROM: <me#domain.com>
250 OK
RCPT TO: <joe#mit.edu>
...
I have 2 questions:
1) Now when the mail is forwarded, what will be the MAIL FROM value? I assume it'll be the same, and therefore will fail the SPF because ns.domain.com doesn't allow mit.edu to send emails using its domain.
2) If I'm correct in 1, why not just set MAIL FROM to be the forwarder's identity (is this case, mit.edu)?
Classic email forwarding standards (e.g. ~/.forwward) had been created well before spam era. They keep envelope sender (MAIL FROM:) unchanged => it may cross restrictions imposed via SPF record.
Some forwarding methods (e.g. procmail, ~/.procmailrc) allow to forward with new/changed MAIL FROM:.
SO you should be very specific about MTA/SMTP server doing forwarding.
Relaying is handled by SRS, but that's not the same thing as forwarding. What you're asking for is essentially forgery, so SPF doesn't like it. The solution is not to attempt to preserve the from address, because it's a forward, not a relay.
I am trying to help out a little non-profit organization, who has decided to let One.com host their domain, including website and e-mail. Now, my issue is that One.com does not add SPF-records or DKIM-keys to your domain and I believe that is the reason why a large number of mails sent from the domain, end up in spam.
I've been in touch with their support, who kindly answered:
You are already using our mail servers, there is no need to use SPF for that.
Our mail servers already have SPF installed, and if you are using our mail servers, SPF will not be question since domain is hosted here and it is using One.com's mail server. SPF will only be required if your domain is hosted here but is using a different MX record or mail server
I've tried to figure out if you can leave out SPF, but all I've been able to conclude is that proper SPF on each domain is definitely the proper way, instead of just the hosting companys main domain. I mean, if it was that simple, how come even Google Apps, Zoho, Rackspace etc. recommends adding SPF, if it worked just as well leaving it out - you'd be using their MX as well, so isn't that the same? And wouldn't leaving SPF out leave us with the same issues as before SPF, namedly that you'd have no way to validate if mail was truly being sent from the owners of the domain or just somebody imposing.
So what it comes down to: Can One.com really leave out SPF records on their clients domains, send mail on the clients behalfs and still expect mail to come through without ending up in spam more often?
Thank you very much for your time!
The short answer is "No, they can't". The longer answer is a little more complicated.
SPF uses either the EHLO domain of the sending server or the domain in the Return-Path to look up SPF records in DNS. Most systems that handle multiple domains do not use SPF records on the EHLO domains of the sending servers, so the SPF domain is taken from the email's Return-Path. You should take a look at the Return-Path for one of the emails that this non-profit has sent through One.com to determine whether the Return-Path is on a subdomain of one.com, or is using the non-profit's domain. The latter is definitely preferred.
If the Return-Path is on a subdomain of one.com, then that's the domain that will be used to look up SPF records. So adding SPF records to your non-profit's DNS won't do anything. While this may seem the easier path, it causes problems with DMARC and may cause the email to be flagged as spam even if it passes SPF, as the address in the 'From' header will have a domain that doesn't match the Return-Path
If the Return-Path is on a subdomain of your non-profit's domain, then you should definitely add an SPF record to your non-profit's DNS. Looking at one.com's current records, something like:
v=spf1 include:_spf.one.com ~all
should do it.
By the way, you should be able to see whether an email has been SPF or DKIM authorized by looking at the headers of the received email. That's the best way to understand the actual behavior.