SPF and DMARC additions
hello I havent used cloudfare before, i am trying to add the following
Google & Yahoo are enforcing new requirements, which means tweaking our email settings to mark marketing messages going out safe. Can you please help me out by adding the following records: SPF Record: Record Type: TXT HOST: @ REQUIRED DATA: include:4114118.spf06.hubspotemail.net (http://4114118.spf06.hubspotemail.net/) DMARC Record: Record Type: TXT HOST : _dmarc REQUIRED DATA: v=DMARC1; p=none;
I added 2 txt files but the changes arent working. does the data above look correct?
29 Replies
The
include: thing looks correct as a part of a record, but not as being the only content of the record.
Requiring the p=none; part of the DMARC would be questionable, and you should do whatever you can to steer that towards p=reject; ASAP.
However, before moving it towards p=reject;, you need to verify that your set up (e.g. DKIM authentication) is done properly first.
What domain is this about?presentation-company.com
i keep making adjustments to see what would work
You got two SPF records, whcih is incorrect.
You got two records that are partial SPF records (e.g. should have been content within your actual SPF record, and not it's own record).
Delete this one.
i deleted it
Are you using Amazon SES to send mails?
i am confirming but i think so
In one of your includes above, you have "
include:amazones.com", which could very well be a typo of amazonSES, which you may have typo'ed as amazonES instead.
If you can confirm Amazon SES is being used, it needs to be corrected, and if Amazon SES is not being used, then I would delete it.
include:amazones.com currently points to a defective domain, which ... may cause issues with your SPF.
Next, you need to verify - are you using Mailchimp to send mails?
If not, that (include:servers.mcsv.net) should be cleaned out too.
MX points to Office 365 / Outlook, so I assume you are using them for both inbound and outbound messages, which would be the last one I see, the include:spf.protection.outlook.com.once i confirm the info, can we setup a session to clean up? i will send you a venmo first
1. Delete the TXT "
_dmarc" where the content only says "v=DMARC1; p=none;"
2. Delete both TXT starting with "v=spf1"
3. Delete the TXT starting with "4114118.spf06.hubspotemail.net"
4. Add ONLY ONE of the following, depending on which ones you can verify you send emails with:
Office 365 & Hubspot:
@ TXT "v=spf1 include:spf.protection.outlook.com include:4114118.spf06.hubspotemail.net -all"
Office 365 & Hubspot & Mailchimp:
@ TXT "v=spf1 include:spf.protection.outlook.com include:4114118.spf06.hubspotemail.net include:servers.mcsv.net -all"
Office 365 & Hubspot & Mailchimp & Amazon SES:
@ TXT "v=spf1 include:spf.protection.outlook.com include:4114118.spf06.hubspotemail.net include:servers.mcsv.net include:amazonses.com -all"i have 2 starting with v=spf1
Yep, and that's one of the things that needs fixing, where the way to do that depends on which exact email providers you actually use.
ok I am confirming now
Having more than one means that SPF will fail with "permerror", because of an incorrect configuration.
if they dont reply tonight, will you be around tomorrow?
It isn't impossible, but may depend on when exactly 😉
(4 AM with me at the moment)
oh wow lol im eastern time its 10pm. Ill message here to see if you are around
We have to go back to 2013 to find a time where I've been in that timezone 😉
But sure, just talk and I'll talk back when I'm around 🙂
hello
they have office365, hubspot and a LMS called eurekos
i created this spf
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:amazones.com include:4114118.spf06.hubspotemail.net ~all
do i need to make a change on dmarc?
good morning
As there is no MailChimp in that, ... drop the "mcsv" one.
As the domain
amazones.com is broken (and the potential typo "Amazon SES" isn't in that either), drop that one as well.
Given the above information, I'd say replace it with:
"Need" depends on what you want to do...
Do you want everyone to be able to send emails claiming to be from your domain?
Yes? Let it stay.
No? You would need to steer the DMARC towards p=reject;, which may require ongoing assessment (of the DMARC reports) to determine whether or not you're ready to take that step.what do you mean everyone? I want just the users there to be able to use it
I made the update to SPF
what is your venmo?
Email was originally created at a time where there wasn't that many people (or organisations) on the Internet, and that everyone (or, at least the majority) could actually be trusted.
As more and more people (and organisations) came on the Internet, it became apparent that you couldn't just blindly trust everyone to always do the right thing (e.g. to not fraudulently "spoof" someone else's domain).
Extensions like SPF came, which would break with message forwarding, and DKIM then arrived to add a cryptograhic seal to the message. Both of them provide some sort of "authentication" to the email messages, which the recipient's mail server can use to check up whether it believes that the sender is authentic, and not just an imposter.
Later on, DMARC arrived as an extension, to signal to receivers what they should do with messages that fail such email authentication (e.g. where neither DKIM w/alignment nor SPF w/alignment is verifiable).
DMARC has the following policies:
p=none; -> Do nothing, let everyone spoof messages from my domain.
p=quarantine; -> Put unverifiable messages in spam folder.
p=reject; -> Deny the delivery of unverifiable messages.
As mentioned above, it may require ongoing assessment to verify whether your email deliveries currently allows you to switch to a stricter policy.
However, having a "weak" policy allows everyone to spoof messages from your domain, and some (could for example be non-tech savvy people) may believe when they see a message pretending to be from your domain, that it actually is from your domain.
Depending on the content, the final result might be that the users won't be trusting your organisation any more, - because they saw what they believed to be a legitimate message, and acted (incorrectly) up on it.
It could be all from i.e. "Your account has a negative balance and has been suspended, please click here and rectify it" (just an example.com link), ... to whatever else nasty you can imagine.
In the end, it would be your organisation that would lose the user's trust, even if you weren't the sender of that "fake" message.
That's one of the many reasons I'm recommending everyone to steer towards p=reject;, where possible.
For this one, if you're referring to the payment related venmo, I don't use that.
Although I appreciate any kind of offers for a contribution, you shouldn't feel any obligation or that it is mandatory to do so.So I should add p=reject to dmarc setting
Not payment just a thank you
What do you use?
this is my current dmarc
v=DMARC1; p=none; rua=mailto:4f56983204934736b48454950e4edc95@dmarc-reports.cloudflare.net
v=DMARC1; p=none; rua=mailto:4f56983204934736b48454950e4edc95@dmarc-reports.cloudflare.net p=reject
is this right?
Not add, but replace the current value.
Re. "should": As mentioned above, it will be wise to check in every now and then, and look a the information coming in through the DMARC reports, and verify that the legitimate sources are all giving a "DMARC pass" (and preferably, 100% DKIM aligned too).
If some of your legitimate email isn't configured (well enough) with one or more of your providers, they could get rejected.
Before:
v=DMARC1; p=none; rua=mailto:4f56983204934736b48454950e4edc95@dmarc-reports.cloudflare.net
After: v=DMARC1; p=reject; rua=mailto:4f56983204934736b48454950e4edc95@dmarc-reports.cloudflare.netHello
Sorry to bother you
But our emails are being rejected now
That is because something isn't set up right with the sender, e.g. Microsoft Office 365 in the case with your screenshot, as mentioned with the clauses above:
However, before moving it towards p=reject;, you need to verify that your set up (e.g. DKIM authentication) is done properly first.
and here
and here
I would guess that the blurred out thing in the bottom of that screenshot, that it really says something like either:
or
(Difference being s=selector1 veruss s=selector2)
The Microsoft Office 365 admin needs to set up DKIM using this tutorial: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure
(Or skip to the important part here: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure#configure-dkim-signing-of-outbound-messages-in-microsoft-365)
Once that has successfully been set up properly, the DKIM with Microsoft Office 365 will then be in a perfect state, and the DMARC rejections will go away, even while keeping p=reject;.