If I add a default DKIM key (default._domainkey....) for a domain, could that interfere with email sent on behalf of that domain from 3rd part mailing services such as Google and Outlook?
To give context and clarify what I'm asking, I host multiple different websites in WHM/cPanel hosting. Many of these websites have contact forms that use PHPMailer on the local web server to send emails from the websites. I was going through all the accounts adding the default DKIM records to improve email deliverabity for these emails sent from the websites. Then I noticed this message in cPanel: "If you send email from another server, you must use this server’s DKIM key on the remote server." Many of these domains use a third party service for email. So that got me wondering if adding the default domain key could cause DKIM to fail when email is sent from those 3rd party services.
I realise that a different (from the default) DKIM key can optionally be added for such services (e.g. google._domainkey....) but if these 3rd party DKIM keys are not added to the DNS records for the domain, then what I'm wondering is if the default DKIM key comes into play for emails sent from those 3rd party services. And if it does come into play, then I guess it would cause a DKIM fail?
DKIM verifies the sender and the integrity of a message. In addition, it allows an email system to prove that spammers did not alter an incoming message while in transit. DKIM also verifies that the messages your domains receive come from the specified domain.
DKIM are important for ensuring that your domain is not delivered to your recipients spam folders or even outright rejected. Mostly hosting providers enables these by default for all cPanel accounts. Third-party DNS providers may require you to add these records manually.
So, answering your question is yes having wrong DKIM record will be a problem. You should add your 3rd party DKIM record in your cpanel.
However missing/ not having DKIM is different scenario as it shouldn't be a problem. Having the DKIM key on your messages is a 'advantage' as to indicate the spam filters and other mail servers that these messages are valid messages. But, not having the DKIM key would not be considered a 'Fail'.
Related
I don't have any technical problems, but I have a question that I would like to be answered out of curiosity.
Here is my current understanding of how email works:
One of the privileges of having your own domain is that you can hook it up to IMAP/POP3/SMTP servers and use them to send and receive messages to and from "anyone#yourdomain.com". With spam being such a problem, however, the SMTP server that you use to send messages must add a bunch of headers (DKIM, SPF, etc) to each message that you send in order to prove that the SMTP server has the authority to send emails from that domain. The receiving SMTP server can cross-check those headers with DNS records that it finds to verify the legitimacy of the email message.
So if you want to send emails with your domain cheaply, you can use Gmail's "Send Mail As" feature. I followed this help article to get mine working: https://support.google.com/domains/answer/9437157
Note: I unchecked the "Treat as an alias" option during the setup.
But wait... no additional DNS configuration required? I have my domain registered with Cloudflare, and there are no entries related to Google in there.
There is this step in the setup process:
But it seems that this only for Google to prevent you from using their servers to send spam. What is stopping Google from impersonating any email address they want? Why do receiving SMTP servers trust an email from "anyone#yourdomain.com" if Google's SMTP servers have no way of adding legitimate SPF/DKIM headers?
The short answer is that nothing prevents Google from doing this, and that DMARC was created for exactly this case.
There is nothing that stops Google from impersonating any domain. However, there are things receivers can (and should) do when they receive an email which isn't send from the server indicated in the From: field.
Try sending an email from the alias you just added to a different #gmail.com inbox. You will see that it says via gmail.com behind the sender email address. But other email receivers might do more: flag this message with red exclamation marks and scam warnings, throw it into spam or even deny receiving it completely. Gmail probably has some hardcoded trust, but try doing this from your own SMTP server and the above will very likely happen.
As you say in your question, you can authorize your emails by marking gmail.com as an authorized sender with SPF (which protects against forging from other domains, but doesn't stop Google), or even sign your emails with DKIM (not possible from Gmail UI, but you can do this in some email clients or send email with a custom Python script like me; Google can't do this without knowing the key).
However, that only solves one side of the problem – authorizing legitimate email messages. But what if an SMTP server still receives an unverified email? What if they have previously received an email from the same sender which was DKIM signed? What if DKIM passes, but SPF fails?
Because the behavior in that case is largely unspecified, and also the sender wants to check if their DKIM/SPF authorizations are actually working, and if anyone is attempting to spoof them, another standard was created: DMARC. It introduces another DNS TXT record where you can say what checks are required to pass, what to do if they fail, and also what basic analytics should the receivers report to the owner of the domain.
Of all webmail client providers, Google's Send mail as is actually the most well-implemented for a variety of reasons.
First of all, how it works is not different from when you set up POP3 or IMAP using a mail client like Outlook or Thunderbird. You have to specify the domain and port where you receive emails from, and the domain and port where you send emails from. For example, Google's incoming and outgoing servers for IMAP are as follows:
imap.gmail.com:993
smtp.gmail.com:465
The Send mail as feature is a partial implementation of that. It only implements the outgoing part.
How mail clients like Outlook and Thunderbird send emails, is basically that it sends the email to the outgoing mail server, and the outgoing mail server then sends the email. Usually, outgoing mail servers will require some sort of authentication, and will allow authenticated users to only send from specific email addresses.
Gmail works the same way. The outgoing mail server is the one that has to pass the SPF and DKIM tests, not Google's servers.
No other webmail clients do this. Hotmail used to do this, but they recently removed the feature. Now, the option is very difficult to find, and they just rewrite your FROM address and sends your email from Hotmail's SMTP server, which creates delivery problems.
They don't provide you with the option to send emails from another SMTP server, because this allows people to very easily set up virtual mail servers that can send emails under a domain of your choice, but use say a typical free Hotmail account to store incoming mails. This takes away business from their paid services, because both Hotmail and Gmail sell the option to host your company emails. I'm sure Google also knows about this, but it is really awesome of them to still keep the option available to free Gmail users.
If you want to learn more about virtual email servers, you can check out this article here: https://blog.terresquall.com/2022/01/setting-up-a-virtual-postfix-mail-server-part-1/
I'm trying to setup a SPF record on Microsoft Azure, because currently our emails are considered as spam.
This is the record I've added:
But it doesn't seem to work, since https://www.kitterman.com/spf/validate.html returns this when I test the SPF record for my domain:
SPF record lookup and validation for: check-in.green
SPF records are published in DNS as TXT records.
The TXT records found for your domain are:
fidelise-rpfc.azurewebsites.net
Checking to see if there is a valid SPF record.
No valid SPF record found of either type TXT or type SPF.
Can anyone please tell me what I'm doing wrong?
It might be marked as SPAM not just because of SPF record but because of DMARC & DKIM as well.
If you are using 3rd party mail delivery provider - check their dash board for values. If you are sending emails yourself directly, here is a my cheat sheet:
1) DNS _dmarc record:
TXT/_dmarc/v=DMARC1; p=none; fo=1; rua=mailto:dmarc_agg#check-in.green; ruf=mailto:dmarc_afrf#check-in.green
2) DNS spf record: your is fine
TXT/#/v=spf1 a mx include:_spf.perfora.net include:_spf.kundenserver.de ~all
but usually you have to specify only one type of outbound ip address (you can check IP in actual messages that been delivered, e.g. Gmail have 'show original' option on email):
a - when you send from IP that can be resolved as A record (check-in.green web server itself)
mx - when you send from the same IP as in your MX record (if you have dedicated mail server for incoming emails and the same server sends outgoing for your project)
includes - usually for 3rd party mail delivery services, like mailgun etc. So, receiver will continue query for another record until it get a full list of IP or until 10 queries made.
ip4:xx.xx.xx.xx - when you have specific IPs for your outgoing relays (or your web servers have dedicated interface for this to avoid exposing real server address behind CDN)
3) DNS DKIM record: generate an RSA key pair (e.g. http://travistidwell.com/jsencrypt/demo/)
Set the public part to your DNS record:
TXT/rec1._domainkey/v=DKIM1; p=MIIBITANBgkqhkiG9w0BAQE....TsddAgMBAAE==
4) Make sure you message have DKIM-Signature header made with private key and marked s=rec1 (as in DNS DKIM record).
Also, do not forget to check your message in test recipient mailbox (e.g. gmail). Here you can check if all 3 validation are passed:
you are using azure, so, keep in mind they can block outgoing SMTP or redirrect via their own servers
I switched to use Mailgun from Sendgrid for email sending, we have several domains which would like to send email via Mailgun, to verify a domain, it requires for lot of DNS configuration like TXT, CNAME, MX... while with Sendgrid, it just asks me for 3 CNAME.
I'm not sure why Mailgun requires to configure much DNS information like that, does it take any advantages over SendGrid with just CNAME, if not, I think they should investigate and apply the Sendgrid way.
To clarify the use of each type of record for such mail service, For sending an email all you need to do is verify that you own the domain from which you are sending the email, they way these companies verifies the domain is by checking the DNS entry for either a CNAME or TXT record. Ideally post this verification you should be able to send email from either of the service.
The requirement of adding the additional records in the DNS zone are for use cases like -
TXT records - DKIM and SPF records, Adding these records ensures that your emails doesn't go to spam as the other email service providers verify if its a valid email from a valid sender using DKIM and SPF records. So you need to add the DKIM and SPF records.
CNAME record - Now a days everyone wants to track the email activities done by the users on the email sent to them. Activities like email opens, link clicks etc. These can be done by the email service providers but the urls of the links are converted to the email providers domain urls for tracking. If we want to have our own domain name for all links in the email including the tracking links, thats where a CNAME record for a subdomain is mapped to email providers domain and than that subdomain is used for all links.
MX record - This is required in case you want to receive emails via the email provider of your choice. If you are already using some other email provider for receiving the emails on your domain, you don't need to set up this.
I've a small SaaS where each client gets a subdomain (stackexchange.my-saas.com)
I've a mailgun account where my main domain is setup and I've created a wildcard SPF record in my DNS and if I add additional domains to my mailgun account with a subdomain, they all verifies correctly.
My question is, do I need to add every new clients subdomain as a new domain in mailgun when I have the wildcard SPF record set or can i "legally" just create a from-address for each new client so the header of the emails will be from: Stack Exchange On My SaaS<noreply#stackexchange.my-saas.com>
Sending:
For sending, there is no need. As you point out, you can have the SPF records set so your email can be sent From: whatever subdomain. Note however that Mailgun will add a Sender: header with your Mailgun registered address if your specified From: address has a different domain.
From: Stack Exchange On My SaaS <noreply#stackexchange.my-saas.com>
Sender: noreply=stackexchange.my-saas.com#my-saas.com
Receiving:
For receiving emails, it's a different story. This is a Mailgun limitation and has been answered in this other question.
Basically, Mailgun uses the same MX servers for everybody, so when they get an email they need to look up to which customer the email belongs to, much like any regular multi-host mail server.
(UPDATE) They allow to register wildcard subdomains, combined with a wildcard MX, it might just work for every subdomain. Note however that because of how DNS works, there is no standard way to define BOTH a wildcard MX and a wildcard CNAME in the same domain. CloudFlare is currently supporting this but it will fail for most other DNS providers.
Alternatively, for receiving emails in your SaaS, you have to register each of your subdomains with Mailgun independently (possible through their API). Note that this also implies verifying the domains adding TXT records for each one on your DNS.
Let's start with understanding how email works. Receiver of the email checks for the dns records of sending domain for example your primary domain is yourdomain.com and email is sent from yourdomain.com will work since you have record created under this already when your email is sent from saas.yourdomain.com then DNS record for saas.yourdomain.com should exist or else it will fail to deliver to inbox. Mailgun asks to verify to make sure it is delivered to inbox and receiver makes sure by checking DNS that it is coming from authentic person by looking up at the DNS.
So the answer is as long as your sending domain is same then you will not create it but if your sending domain is different then you will have to create
Hope this answers your question.
I installed on a Google Compute Engine postfix as a MTA.
The Mails are sent via sendgrid.
Now any Mails (tests, errorlogs, cron...) to GMail are marked as Spam.
Sending the same mails from an normal server without sendgrid is no problem.
(I have many root-server and are just trying sendgrid)
Why does google think that every mail from sendgrid is spam?
try with this:
https://serverfault.com/questions/115161/fixing-my-mtas-poor-reputation
and Maybe your IP its reported in blacklist.
Try using other reserverved ip address in your instance.
https://developers.google.com/compute/docs/instances-and-network
For maximum deliverability, SPF and DKIM records need to be setup and properly configured in the DNS records for the domain you want to send mail from. Assuming you signed up for the [free tier of SendGrid][1], available to Google Compute Engine customers:
SPF: make sure the string include:sendgrid.net is present. The most basic setup would then be v=spf1 a mx include:sendgrid.net ~all, if all email for the domain is sent via Sendgrid this is enough. If you have more complex needs, use an SPF builder, such as Microsoft's.
DKIM: get it from the Google Apps account manager, under 'Settings for Gmail>Settings for Gmail'
After those two are in the DNS records for the domain in question, use the Port25 verifier to ensure all settings are correct. Of course, if you want to test whether mail from the server is properly setup for deliverability, send them email form the server. Same for email from Outlook, etc.
PS1: These instructions vary slightly if you are using a paid version of Sendgrid
PS2: All Google Compute Engine IPs are listed in Spamhaus PBL. Email should not come from these IPs directly (but if you have a specific reason to do so you can contact GCE Support - which is not free - and request that they add a reverse DNS record for you so you can start sending mail from this address directly).