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.
Related
I have an email address forwarding to a gmail account. I then use SMTP to send a response from gmail via the domains SMTP server. This is all set up fine. However some recipients are not receiving the emails? Is there further configuration I need to do on the domain side?
I am told I need to configure the SPF, DKIM and DMARC records but I have no idea what the configuration/values should be?
Having SPF, DKIM and DMARC set up is seldom a prerequisite for having your email delivered. If your email domain and servers have a decent reputation, you won't, generally, run into to much trouble.
However, it is best practice to set up all three, to start authenticating your emails and making it harder for others to impersonate your email domain without authorization. I'll outline the basics for you:
Why Authenticate
Phishing: Email Authentication will make it harder to impersonate your email
domain, without authorization. It (somewhat) protects your colleagues, partners and customers against phishing.
Brand Reputation Protection: Phishing from your domain can harm the reputation of your brand.
Deliverability: Authentication improves deliverability because it's weighed heavily in determining whether or not the email is legit.
DMARC
DMARC will try to find successful authentication for servers sending on your behalf. Specifically, it will look for a Pass on SPF or DKIM, in alignment with the email address (domain) that is being showed to the recipient in his email client. This is known as the Header.From field. (Not to be mistaken with the Sender field, the Reply-To field or Return-Path).
SPF
SPF is basically a list of IP addresses, published as a TXT DNS resource record, listing all servers that are authorized to send email for the domain the record lives in. This does not include subdomains, those require additional SPF records. One of the (many) problems with SPF: Receiving servers need to check the Return-Path email address to lookup the SPF record, instead of the Header.From domain. There is no need for the Header.From email address and the Return-Path address to share any of the domain part, according to the SMTP RFC. Thus where DMARC comes in.
DKIM
Signing an email message with a DKIM private key, requires you to publish a matching public key in the subdomain _domainkey for the domain your signing for. The receiving server will look for d= value and the s= value in the DKIM signature to construct the correct DNS TXT resource record to query, holding the public key. Example d=stackexchange.email s=s1 will result in a DNS query for the TXT record s1._domainkey.stackexchange.email. The same applies here as with SPF: The d= value does not have to match with the domain portion of the Header.From email address.
Unfortunately the configuration and values are very specific, depending on which parties are allowed to send on behalf of your domains, the subdomains you use and how you use them, etc. Especially SPF has a few limits that will make the setup harder.
I host a domain for a client; the domain's A records point to my IP address. When email arrives addressed to someone in his domain, he just wants to forward it to his ISP (charter.net). This works about 90-99% of the time, but a few times a day charter.net rejects the message with 'Service not available'. We tried forwarding to his gmail account instead, and same thing -- it usually works but sometimes gmail returns 'Service not available'. When this happens, my sendmail apparently gives up.
My suspicion is it is not the recipient's server uptime that is at issue; it rejects email that it sees as suspicious.
I have recently added SPF and DKIM records for my server's canonical name but I still get 'Service not available' from charter.net. Now sendmail DKIM-signs any mail that originates on my server, but it is not signing email that it forwards. I have not found a way to configure opendkim to do that. But I have seen that mandrillapp.com resigns email that it forwards; the headers include a DKIM-signature with d=originaldomain.com, and a 2nd DKIM-signature with d=mandrillapp.com.
So I guess my questions are,
1) Does anyone really know why my server gets 'Service not available' from ultimate recipient?
2) Can I configure opendkim to sign email that my server forwards?
3) Might it do any good to set up SPF and/or DKIM records for my client's domain?
Thanks,
Bob
ADDENDUM:
For forwarding, I have entries like this in /etc/mail/virtusertable:
a#clientdomain.com a#charter.net
For DKIM, I have this in my sendmail.mc:
INPUT_MAIL_FILTER(`opendkim', `S=inet:8891#127.0.0.1')
I also have clientdomain.com in /etc/mail/local-host-names, and as I said above clientdomain.com's A records resolve to the same IP as mydomain.com.
Classic sendmail redirects via aliases, ~/.forward file and virtusertable keep unchanged original envelope address (It is used in MAIL FROM command during SMTP session). It may make your forwards break restrictions set by SPF record of the original sender domain.
Possible fixes for "many addresses" redirect:
SRS
custom sendmail.cf fixes
For more details ask at more suited siter site serverfault.com.
I am creating a webservice with Mailgun to send out emails. It will BCC my own domain's email for every email sent out. Assuming my domain is "example.com". For every email sent out to a customer, say, customer1#gmail.com, I will BCC its content to sales#example.com.
Currently, the domain example.com and its email is hosted on a server with CPanel.
In Mailgun, I have added and verified the domain example.com. Using this domain, I've sent a mail to customer1#gmail.com and sales#example.com. The email is sent without issues to Gmail, however when sending to sales#example.com, I keep getting the error Server response: 550 550 Verification failed for <bounce+e0f051.e0179a-sales=example.com#example.com> No Such User Here.
What's baffling here is that if i send the email via Mailgun with another verified domain such as anotherexample.com, and then using this, I send my mail to sales#example.com. The email arrives perfectly fine without errors.
So far, the things I've tried:
Added Mailgun suggested SPF and DKIM
Modified SPF to include my CPanel server's IP (together with Mailgun SPF)
Deleted both the SPF and DKIM (one at a time and both at once)
Verified that the email sales#example.com exists. Using the CPanel webmail's interface, I can send and receive emails just fine.
Tried updating the CPanel MX entries Email routing from Local -> Automatic -> Remote. ("Local" works the best. If its set to "Remote", email sending and receiving doesnt work at all, even if mails are sent through Gmail/Hotmail).
My current MX settings are:
Priority 0: mail.example.com
My current Zone file records on CPanel:
example.com A <some ip>
mail.example.com A <same ip as above>
The code I am using to send mails via Mailgun (Ruby):
mg_client = Mailgun::Client.new 'xxxxxxxxxxx'
message_params = {:from => from_email,
:to => customer.email,
:bcc => bcc_email,
:subject => MessageTemplate.email_subject,
:text => message}
result = mg_client.send_message('example.com', message_params).to_h!
I currently do not have the SPF and DKIM records in the zone files. I've added and removed them and they had no effect on the error (still delivers fine to Gmail too).
I've spend the whole on this, scouring forums and whatnot but can't seem to find a solution.
If at all relevant, I have a 301 redirect of example.com to www.example.com(Which has a CNAME pointing to another server). But I've researched and found out that 301 redirect does not affect emails.
I don't think this is a send-side problem. You're sending to sales#example.com, but you're getting errors relating to bounce+e0f051.e0179a-sales=example.com#example.com, which is a typical VERP address. Now, VERP addresses are fine, so long as you're expecting them. Given that you are not apparently providing that explicit address to MailGun, I assume that they are generating that address automatically. I would check their documentation for how they generate return-path (envelope sender) addresses, and either override the sender address (with just sales#example.com), or configure handling of those VERP addresses on your own inbound mail server.
Here is a mailgun explanation
This error occurs due to what is termed Sender Address Verification (SAV). During SAV, an email server performs an MX lookup upon the domain (example.com) listed within the message envelope's Mail-From field. SAV typically rejects the message if,
the sender's (in this case, Mailgun's) MX records are not configured for that domain AND
the domain of the message envelope's Mail-From field does not match the domain of the message header's From field.
https://help.mailgun.com/hc/en-us/articles/360011804533-Sender-Verification-Error
Is it a problem if 127.0.0.1 appears in email headers?
Example: Received: from baobabsmail.baobab.fi ([127.0.0.1])
I ask because emails sent from my server to #outlook.com addresses end up in the spam folder and this is the last thing I can think of. I have properly configured HELO, DKIM, Reverse DNS, SenderID, SPF and DMARC. I don't send out mass emails. My IP is from AWS, but it isn't on any publicly available blacklists. I have verified that everything is set up correctly using DKIMvalidator, MxToolBox and mail-tester.
Edit: for what it's worth, I finally got rid of the 127.0.0.1's in my headers and it did not resolve the issue for me.
Unfortunately, it depends...
Mail systems vary in how they are configured, and it is perfectly legitimate for an MUA (e.g. Thunderbird) to send outgoing mail to an MTA / mail server (e.g. exim) running on the same machine using the localhost address. Unusual, these days, but not "bad by definition".
When you say 'end up in the spam folder', what is it that puts it there: are you using a local mail server? if so is it that server that junks the mail (on send) or outlook.com itself (on receipt). Either way, what error messages or other failure information have you found?
Some random thoughts:
DKIM is a pain to set up correctly. Try disabling it entirely and see if that changes things in interesting ways.
Ditto DMARC.
Have you got SPF set up separately? If so, disable SPF and retry.
Is IPv6 involved in the mix at all? Various things are subtly different if so.
If outlook.com were to do sender verify callbacks (i.e. on receipt, check that mail from address was an acceptable recipient to your server) would it pass?
Is your email system sending RFC-conformant mail: that is, does it have a From: address, To: or Sender: address, Message-ID:, Date: headers and, if using MIME, Content-* headers (and probably a couple I forget!).
If changing DKIM / DMARC / SPF changes things (and remembering DNS timeouts, leave it a while between attempts), re-add SPF first - it is the simplest to get right.
127.0.0.1 can be flagged by Spam filters because it fails to provide an identity trace of the sender. Most common e-mail systems will show the IP address or the host name. The next item will be the recipient e-mail server.
For example:
Received: from [127.0.0.1] (81.27.148.196) by TAE1.agent.com.pk
What is funny about this one is that the top-level domain says it is received initially by a domain in Pakistan, but the IP address is registered to an entity in St. Petersburg, Russia.
Having a little trouble with dkim, smtp and forwarded domains.
I basically want to use the gmail smtp servers from my google apps account to send mail from one of my domains, but I can't have that domain as either a domain alias or subdomain of google apps (for complicated reasons I won't go into...)
So. I've set up the SPF records for my original domain: domain1
I've also set up SPF records on my new domain: domain2
However, I'm still getting the 'via domain1.com' on my emails.
I think the issue is that I have SPF but no DKIM, but I can't work out a way of getting a DKIM signature that I can pass without making the domain a domain alias which I really don't want to do. (It's not what it's for).
Any ideas?
two things - doublecheck that your domain2 SPF record designates your sending domain domain1.com as eligible to send email for domain2. So domain2 spf record should look something like this: v=spf1 a:domain1.com ~all.
The second thing is - yes, you need DKIM signature but actually it should work in both cases - one when you sign sending domain - here it is domain1.com or when otherwise you sign sender domain - and it is domain2 then.
So you can feel free to try continue with domain1.com and create DKIM for that both in DNS and in GoogleApps with help of GoogleApps control panel. It should work and be enough when you signing domain1.com with dkim as your sending domain.