Although it is not possible to implement a complete DMARC policy with only SPF, due to forwarded emails, is it still possibible to implement a proper DMARC policy with only DKIM?
Yes, it's possible to protect an e-mail domain via DMARC policy solely with the DKIM digital signing technique in place.
The reason is that DMARC requires either SPF OR DKIM checks to pass, not necessarily both.
For more details see: https://datatracker.ietf.org/doc/html/rfc7489#section-2.1 or this similar question: https://serverfault.com/q/812367/268257
However such setup would limit DMARC policy protection only to "header From:" addresses that are typically visible to recipients.
To protect also the invisible "envelope sender" addresses (aka MAIL FROM or Return-Path), used for receiving bounces (Non-Delivery Reports), it's recommended to use the SPF, which is focused on that.
The SPF is also useful when sending emails to recipients that are lacking DMARC support as it gives them at least some hints about sender's authorization.
Thus the best setup is to combine both DKIM and SPF.
Related
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.
Delivery Status Notification (Failure)
550 5.7.26 Unauthenticated email from medi.com.co is not accepted due to domain's DMARC policy. Please contact the administrator of medi.com.co domain if this was a legitimate mail. Please visit https://support.google.com/mail/answer/2451690 to learn about the DMARC initiative. k8sor1812313ybh.196 - gsmtp
Following these steps helped me to solve this problem
How Senders Deploy DMARC in 5-Easy Steps
DMARC has been designed based on real-world experience by some of the world’s largest email senders and receivers deploying SPF and DKIM. The specification takes into account the fact that it is nearly impossible for an organization to flip a switch to production. There are a number of built-in methods for “throttling” the DMARC processing so that all parties can ease into full deployment over time.
1. Deploy DKIM & SPF. You have to cover the basics, first.
Activate DKIM following this
https://support.google.com/a/answer/180504
Activate SPF following this
https://support.google.com/a/answer/33786?hl=en&ref_topic=9061731
Ensure that your mailers are correctly aligning the appropriate identifiers.
2. Publish a DMARC record
Follow this
https://support.google.com/a/answer/2466563?hl=es
3. Test that everything is working with this
https://dmarcian.com/dmarc-inspector/
https://toolbox.googleapps.com/apps/checkmx/check?domain=medi.com.co&dkim_selector=
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'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've set up SPF, DKIM, and now DMARC (reporting only) on my site. Sometimes when my site sends me an email, I can see that my GMail inbox has evaluated SPF:Pass, DKIM:Pass, and DMARC:Pass, but sometimes I only get SPF:Pass and DKIM:Pass, with no mention of DMARC. Do mail servers sometimes skip DMARC tests? Maybe for whitelisted domains or cached senders?
Generally speaking, DMARC is only needed when SPF or DKIM lookups fail, as their main purpose is to say what to do in the event of a failure. There's no particular reason to look up DMARC if SPF and DKIM pass, but I guess gmail must just do it anyway sometimes. Many mail servers don't do SPF, DKIM, or DMARC tests at all. If you had a case where gmail was failing a check and not looking up DMARC, I'd be a bit more concerned.
If you can provide the email header of email where gmail skipped DMARC results, we can analyze the issue. If the FROM domain has configured DMARC record, then gmail definitely do DMARC checks and results will be added on the email header. DMARC results will only be skipped when there is no DMARC record found on FROM domain.
Cheers,
Sundaralingam Subramaniyan