0

My website is up and running on www.example.com and I am sending automated emails from my email address support@example.com. DMARC and SPF seem to setup accordingly:

_dmarc : v=DMARC1;p=none;pct=100;rua=mailto:support@example.com;ruf=mailto:support@example.com

spf : v=spf1 a mx include:_spf.elasticemail.com ~all

However, I keep receiving email reports from google and yahoo saying that my email is not authenticated. When I use free DMARC analysers, it says (as warning):

No DMARC Record found for sub-domain. Organization Domain of this sub-domain is: example.com Inbox Receivers will apply example.com DMARC record to mail sent from www.example.com

Another one says (as warning):

A DMARC record is defined, but there are some issues with the configuration that may impact security, visibility, and deliverability for email sent from this domain.

DMARC is not at enforcement for example.com. Anyone can send messages purporting to be from addresses on this domain or its subdomains.

Whatever I have done, I couldn't overcome this issue. What am I doing wrong? Is it all because my domain is www.example.com and I am using support@example.com subdomain to send the email?

  • 1
    The second analyzer rightly complains about your policy of none. This essentially means that no action (except reporting) is taken on spoofed mails based on the DMARC policy. – Steffen Ullrich Mar 23 '18 at 19:07
  • @SteffenUllrich Should I use v=DMARC1;p=reject;pct=100;rua=mailto:support@example.com;ruf=mailto:support@example.com instead? Because I keep receiving automated emails from yahoo and gmail in daily basis and gmail shows my email as unauthenticated – senty Mar 23 '18 at 19:10
  • I have no idea which mails you refer to (DKIM reports?) but p=reject will reject spoofed mails. But you should probably check the DKIM reports you've got so far to make sure that only mails you want to have rejected are classified as unauthenticated so that no expected mails get rejected. – Steffen Ullrich Mar 23 '18 at 20:34
0

"My website is up and running on www.example.com and I am sending automated emails from >my email address support@example.com."

When these automated emails are sent from your website or application, it sounds like they are being sent using their own mail server without any SMTP authentication. For example, a website may send out user registration email confirmation messages using sendmail or postfix mail server software which is commonly installed on web servers for this purpose, however those who send spam or spoofed email messages use the same techniques and can also claim to be sending email from support@example.com. With some configuration, your website could be sending authenticated emails, i.e. instead of using the built-in mail server software, the website connects to your domain's main SMTP server (could be Exchange or Office365 or Google etc, other mail server brands exist), authenticates with a username and password, just as you would if you were using an email client application on your phone or webmail, and then it sends the email.

"No DMARC Record found for sub-domain. Organization Domain of this sub-domain is: example.com Inbox Receivers will apply example.com DMARC record to mail sent from www.example.com"

In the absense of a sub-domain DMARC record, the main record for the domain will apply. Unless you are using email addresses like support@subdomain.example.com this is not likely to be an issue. You could ensure there will be an SPF fail in this case by have a wildcard SPF record to cover any subdomains spoofers may think of, for example: v=spf1 -all, and enter * as the hostname for this record. This will not interfere with the SPF record you have created for the @ which covers your normal use of email for the domain, email addresses such as support@example.com.

"A DMARC record is defined, but there are some issues with the configuration that may impact security, visibility, and deliverability for email sent from this domain."

Without more investigation it will be difficult to tell exactly which issue this may be referring to, however it might be as simple as the fact you're specifying an email address with the same domain name for the reports to be sent. If there are email delivery issues with the domain example.com your reports about it may not be received at support@example.com! Perhaps setup support@example.net or other different domain for processing your DMARC reports.

"DMARC is not at enforcement for example.com. Anyone can send messages purporting to be from addresses on this domain or its subdomains."

This simply means you have p=none or p=quarantine at the moment. The first is ideal for when you're just getting started and need some oversight as to what's going on without wanting to cause problems unnecessarily. The second is a good mid-way point to start seeing messages quarantined (moved into Junk folders) when you're testing the effectiveness of which ones it blocks and doesn't. Eventually the aim for most organisations will be to set this to p=reject in order to ensure the messages simply get dropped and are never received. Since DMARC forensic reports are rarely implemented at present you might actually be safer going for quarantine until you are entirely satisfied that those being quarantined includes no genuine messages. Some tweaking may be required before you move to p=reject. The message you're seeing doesn't mean you've done anything wrong, just that your implementation is at the early stages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.