I'm troubleshooting an issue involving duplication of emails sent from an SSRS server via office 365 to customers. During investigation I looked at the email headers from duplicated emails and found that they all indicate the following:
received-spf: Fail (protection.outlook.com: domain of myDomain.com does not designate XX.XXX.XXX.XX as permitted sender) receiver=protection.outlook.com; client-ip=XX.XXX.XXX.XX; helo=;
What would be the effect (if any) on emails from myDomain.com (which is our office365 domain name) to various customers considering the above spf Fail message? I do not recognize the ip address however the domain name and hostname are correct.
The effect would depend on whether you have set DMARC record for your domain or not. If YES then whether you are signing your outgoing mails with DKIM or not. If your mails fails the SPF check at least they should pass the DKIM verification.
Related
If I have a domain example.com that is using gsuite (DNS settings at registrar has gmail cnames, spf & txt records etc) and I have another service sending on behalf of the domain (Klaviyo). Do the gmail DKIM and DMARC settings help to strengthen the deliverability of those emails sent by the other service (Klaviyo)?
To answer your question: A DMARC reject or quarantine policy helps improve deliverability for all parties that send on behalf of your domain AND properly authenticate by SPF or DKIM, in alignment with your domain.
DKIM consists of a cryptographic key pair. You publish the public key on the Internet and you use the private key to sign headers of your outbound emails. This signing is done on the sending server. So unless Klaviyo is using Google servers to relay your messages, those messages are not being DKIM signed by Google.
You should follow the instructions provided by Klaviyo here, so that the emails you send from their platform, using your email domain, will authenticate properly and will NOT fail DMARC.
Update:
Say you own the domain myexample.com, then you should publish a TXT record at the root of that domain that looks like "v=spf1 include:_spf.google.com ~all". Additionally you can add any other services or servers to this record as you see fit. You don't need to add Klaviyo to your SPF record as they will try to authenticate from the send.myexample.com domain used in the bounce address. That is what you created the first CNAME for. It redirects to an SPF (and MX) record hosted at Sendgrid. Additionally, Klaviyo will authenticate those emails using DKIM.
In order to make DMARC work, you need to publish another TXT record at _dmarc.myexample.com, if you haven't already, looking like: "v=DMARC1;p=none;rua=mailto:DMARC#myexample.com;". Then you'll start receiving aggregate reports at the mailbox you supplied. Once you're confident you've included all required parties in your authentication scheme, you can move to a p=reject policy in order to protect your domain.
Yes, DKIM and DMARC settings do help deliverability.
I assume that Klaviyo does what my company Autoklose is doing as well, and that's using Gmail API to send the email in your name. That means that they only indirectly affect the sending process and the email itself is sent from Google servers and not Klaviyo's servers.
Also, you have to be aware that DKIM & DMARC are only two of the factors in successfully delivering your email. For example, having DKIM & DMARC correctly set gets you positive points but if your domain is blacklisted, it still might not get delivered.
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 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.
SPF: fail (Exclaimer Mail Utilities: domain of domain.co.uk does not designate 194.xx.x.xx as permitted sender) client-ip=194.xx.x.xx; envelope-from=user#domain.co.uk; helo=smtp1.bt.net; ########
This is the bounce back that is being received, what does this mean and how can I go about resolving this issue?
we had something similar happen to us. I believe Mail Utilities checks the SPF record for your domain in DNS but this does not match the host address your email address is coming from. Because the two do not match the message has been classified as an SPF Fail and rejected. Try checking your SPF record in DNS for your domain. You might be able to find more info here http://www.openspf.org/.