I would like to have a DMARC Reject policy, but having some issues making it pass.
We use google apps/mail for our domain and use 2 third party email providers who send e-mails as us. I'm trying to make one of them work for now and to understand the process so i can add the second easily.
I'd like to understand how to allow them to pass DMARC.
Right now SPF and DKIM both pass (as per DMARC report), but with a reject policy - it stops with "fail-unaligned"
Trying to understand the details HERE, I believe i need to create a subdomain dns record "email.mydomain.com" and set the From Address in the third party service to be "info#email.mydomain.com". However I'm unsure how i need to setup the DNS.
Do i need to create only a TXT record with SPF in it?
Do i need to create a CNAME email.mydomain.com?
I'm trying to be strict with reject policy so i can learn how to keep things in control, so i would appreciate some tips.
strict alignment means you need an exact domain match. The DKIM d=same domain name space as the visible headers (envelope) headers that indicate the From Name.
Relaxed alignment enables you to have sub-domains.
A solution is to check your ESP documentation to see if you can just add a custom return path (bounce header) that points to the ESP's bounce header (bouncerzzzz.example.com). Note: You'd do in your DNS.
Or you might have to just ask your ESP to sign your emails with a custom DKIM key. You'd publish the public key in your DNS. This is a fairly common approach.
I'd back off from the reject policy for a while, using "reporting" maybe for a month or two. It's good to make sure things are all working and you know who should be using your domains in email and who's using it for nefarious purposes. Get a lay of the land, then set to reject.
Related
I'm currently running a SAAS application and mails are being sent from our application using Mailjet.
Some of the larger customers have been asking to allow the emails to be sent from their domain (e.g. info#largehotel.com) instead of our system (notifications#saasapp.com).
Are there any initial pointers I will need to look at? I'm guessing they will need to add our SPF records to their SPF records too and that they will need add a DKIM key that we generate for them to add to their records too? Then do some validation on them on the DNS level and mark them as validated?
I have some understanding to have customers run their own domain against our SAAS domain but a bit lost on the sending from their email domain requirement.
First, for the record, my SaaS platform does this (vía option 2b). It’s an e-commerce marketplace and I need the receipts to be sent from the email address of the product seller, not from me (the marketplace)
You have two(ish) options
Send email through your client’s mail servers (instead of mailjet)
Verify the client’s domain on your Mailjet (or similar email) service
option 1
With option 1, you’ll need to ask your client’s IT team to setup a username and password for you to access their SMTP server. This is essentially just like them creating an email account for you to use. This may seem like the easiest path available for you, but there are potential pitfalls and disadvantages:
Doing this, you will lose the mail open/click/bounce tracking functionality you get with mailjet; because you’ll be using the company’s SMTP server instead.
If you’re sending out as a fairly common email address (eg info#your-client.com) the client may already have that account active on their mail servers. That would allow them to receive replies into the existing infrastructure but make them wary of the security issues with sharing a password to their mail server with you.
You might find that they don’t even have the ability to give you a username and password. Modern mail services don’t allow for SMTP access (which is what your web app will need); and security conscious companies require 2 factor authentication on mail accounts (which your web app can’t answer)
Option 2
For this, you will need to ask their IT team to configure some DNS records to prove to mailjet, and to the email recipient, that you’re allowed to send on behalf of your client.
You did this for your own domain when you first setup mailjet. See https://app.mailjet.com/support/how-to-add-a-sender-address,96.htm for what this involves, but it’s a case of asking the client to configure a DNS record.
That tells mailjet that you’re allowed to send on behalf of that domain; but you’ll also want the client to adjust their SPF and DKIM records so as the recipient of the emails knows to trust Mailjet’s servers with emails sent from your client’s domain name. Normally, recipients only trust email sent from your client’s mail server (which you have as option 1) and distrust email sent from SAAS providers.
You will (or should) have done this on mailjet for your own domain already as well. https://app.mailjet.com/docs/spf-dkim-guide
So for this, you’ll need your client to setup 3 DNS records.
If you go this way, you could setup a separate Mailjet account which they and you have access to. That way they ca see their dashboard directly and feel a sense of ownership and security around it. But you won’t be able to markup the price of it 😜
Conclusion
How important is the tracking? If you can’t lose that you need to go with option 2.
How technically savvy is the client? Are they going to be able to have those DNS records changed? Are they going to be (rightly) security conscious around giving you an account on their main mail sever.
Option 2 would be my preference. You might need to hold their hand through the DNS setup so get it configured on Mailjet (And ask about SPF in here to make sure you get it right) so you can provide them with clear instructions of the specific 3 DNS records to create/update.
Whatever approach you take make sure you’re talking to the right people at your clients side soon. Their marketing team may be keen to do this with you, but if their IT feels left out of the conversation they will be difficult to get on board when you need them to make the changes. Us IT folk can be grumpy and obstinate 😀
your web app
This is going to need some adjustment. You probably already store your Mailjet credentials in a file or environment variables; these might need to move these to a dB table so you can relate credentials with specific accounts. But we’d need more info on the web app to be able to speak more to that side of the challenge.
option 2b
just as a note instead of a real suggestion. Be aware that some email service provers allow the sending verification part to be done by sending an email to someone on that domain (eg admin#yourclient.com) and then allowing sending vía the API if the recipient clicks on the approve link on that email. But, even with that setup you still need the client to configure SPF and DKIM on their DNS, so the extra one record isn’t a big ask. AWS’s SES allows for this. This works for me; but I have different requirements around deliver ability, and a large number of non-tech users (as opposed to your one or two big clients)
you can ask your client to generate programmatic(app key/password) user for email need to use for example info#largehotel.com and some other info like (host:gmail, protocol: smtp,...) all basic info needed then in your saas retrieve all this info to create object with client info that you stored before to send email for the target (from developer prospective non network engineering )
The SPF is the most important think to do. In most cases you have to be very careful about the IP reputation, but since you are using Mailjet it's up to them to manage this part.
Be attentive to the overall quality of the email, text/image ratio... Also offers a text body version of the content and dont forget the unsubscribe link. Since you already send emails with your service, I guess it's points are already correct.
I am having a little trouble figuring out this process. I can manage to get the DNS records set up for the DMARC, DKIM and SPF. I get lost with what i am trying to do with the private key for the DKIM. Currently i am using a dedicated server offered by 1and1.com. if someone can give me a quick walk through i would really appreciate it.
The website i am currently making sends out scheduled emails plus emails on behalf of users. Some of them are being blocked by Hotmail and other email providers. I understand that adding these protocols will increase the likelihood that the emails reach their intended targets. If there are any other mechanisms that can accomplish this as well, i would greatly appreciate a heads up.
i use the built in php mail method to send emails (i do not want to incorporate a third party plugin to do something that php already does and works pretty well)
thanks
Yes, you can set DMARC on 1and1. Set:
Type: txt
Prefix: _dmarc
Value: v=DMARC1; p=none; sp=none; rua=mailto:yourmail#hotmail.com;
ruf=mailto:yourmail#hotmail.com; rf=afrf; pct=100; ri=86400;
Change the 2 emails
You can't set up DMARC or DKIM on 1&1 DNS, they don't allow underscores (_) in sub-domains in their DNS records.
Sorry for the bad news. They are the only hosting provider I know about that doesn't allow underscores (unless something changed recently)
DMARC is easy to set up just use this DMARC Wizard
DKIM is something that you need to set up with email software program you're using to send mail (which you didn't tell us what you're using) - I'm guessing postfix or exim?
I've had a good search on Google but can't find the answer sorry...
We're an Australian company who use a .com address as our primary contact point. Unfortunately sometimes people email to foo#ourdomain.com.au and so the email bounces.
I know I can manually create entries to forward the .com.au addresses to their .com equivalent, but it's not a particularly viable solution longer term.
Is there a way to automatically do that mapping at a server level? We have root access so I can set up whatever is required in that regard.
To re-iterate, everytime someone sends an email to:
foo#ourdomain.com.au
it needs to forward to
foo#ourdomain.com
and I'd prefer to automate the mapping as email addresses are added / removed quite regularly.
We are also using PLESK if that makes a difference.
Thanks...
Sounds to me like you don't need to forward at all. Just set the MX record for ourdomain.com.au to be the same as the MX record for ourdomain.com. Then configure the mail server to accept mail for both domains. The only case in which this isn't viable is if there are actually legitimate .com.au addresses that need to be handled by a separate mail server.
I have a web app at which visitors are signing up and getting a newsletter to the email they registered with.
I am using only a single email field in the signup form, since I wish to reduce the number of fields plus I figure most people (like me) copy and paste the email which mean a typo would propagate to the secondary verification field.
My problem is that a fair percentage of the signups have a typo in the email address, e.g. #yhaoo, #hotmaill, etc.
How can I effectively deal with such typos?
I was thinking of doing a simple auto-correction by using a list of misspellings for common domains, but I can't a ready-made comprehensive list for that.
When the form is posted, you can do an DNS lookup to see if there is a MX record for the domain. If there is not, you can be almost certain that it is a typo, because sending to that address would not get delivered. Then you could re-display the form with a friendly error message, asking the user to confirm that the email address is correct.
Don't auto-correct without prompting the user. It will be very hard to get right, and you might end up with confused users, that have their email address on a domain that closely resembles another domain.
I had this same question, and I just found a free javascript library at http://getmailcheck.org that I think will solve our problems:
The Javascript library and jQuery plugin that suggests a right domain when your users misspell it in an email address.
When your user types in "user#gmil.con", Mailcheck will suggest
"user#gmail.com".
Mailcheck will offer up suggestions for second and top level domains
too. For example, when a user types in "user#hotmail.cmo",
"hotmail.com" will be suggested.
Similarly, if only the second level domain is misspelled, it will be
corrected independently of the top level domain.
It is supposedly used by Dropbox, Lyft, Kickstarter, Khan Academy, and more.
First, you should first make a DNS lookup to see if there's a valid MX record for that domain (which implies the domain should exist) - if not you shouldn't accept that email.
Second, look for an http redirect from the domain to another domain. E.g. yayoo.com and yahooo.com both redirect to yahoo.com, so you may want to show a warning message "Did you mean ...#yahoo.com ?" or even automatically correct the addresses from a whitelist that you've made sure are safe to correct.
Lastly, if there's a valid MX record and no redirect, your remaining culprits will most likely be just typos that lead to hitfarms riding on typos for large providers (or innocent other services) e.g. gmial.com. For these you can resort to manually building a hash table of auto-correct suggestions (again, offering the user a "Did you mean.." step before accepting the submission.
I know that the question is old. But maybe my answer will help someone.
I'm using Mailgun API to handle typos in email addresses.
I've noticed that the domain
contoso.com
is often used in documentation when a sample is needed. I always figured this was a dummy domain, used like the telephone prefix "555" to route spam into some kind of telecommunicative void (although contoso.com appears to be a real site).
Is there a domain I can safely use when I have to, say, test a registration form 20 times with a unique email address and I don't care what happens to the message, yet I don't want it going to a real person?
You can use example.com. According to the Wikipedia article:
example.com, example.net, and example.org are second-level domain names reserved by the Internet Engineering Task Force through RFC 2606, Section 3,1 for use in documentation and examples. They are not available for registration.
By implementing the reservation, the Internet Assigned Numbers Authority (IANA) made available domains to use in manuals and sample software configurations. Thus, documentation writers can be sure to select a domain name without creating naming conflicts if end-users try to use the sample configurations or examples verbatim.
When an address such as "yourusername#example.com" is used to demonstrate the sign-up process on a website, it indicates to the user they should fill in an actual e-mail address at which they receive mail. "example.com" is used in a generic and vendor-neutral manner.
These domain names resolve to a server managed by ICANN.
I started using whatever#example.com for this purpose, but then I began getting responses back from my outgoing email server saying delivery to that address had been delayed. I don't know about the OP, but I want something that I can send to and completely forget about it.
Now I'm changing over to whatever#mailinator.com -- I know that it gets delivered to their catchall (so I'm not getting any junk back about delivery errors), and if I like, I can even go check at http://mailinator.com/ to see if the email went through as planned. (But it's not clogging up my inbox if I don't care about it.)
http://www.faqs.org/rfcs/rfc2606.html has all the standard reserved names. Notably, example.com and the like started resolving a few years ago. Before that they were truly reserved names, not even found in DNS. But they are still useful "fake" domains.
A simple way of testing email delivery is to use Gmail with the "plus" rule. We use this when registering our shared email account with some services that use unique email addresses as the username. This enables us to use a single inbox for all of the incoming registrations and filter the messages to all go to the same folder.
http://fieldguide.gizmodo.com/how-to-use-the-infinite-number-of-email-addresses-gmail-1609458192
One trick you may or may not have picked up about Gmail is that you
can add in periods anywhere in the front part of your address and it
makes no difference whatsoever: john.smith#gmail.com works just the
same as johnsmith#gmail.com. What's more, you can add a plus sign and
any word before the # sign (e.g. johnsmith+hello#gmail.com) and
messages will still reach you. If these tweaks make no difference,
then why use them? One major reason: filters.
how about example.com?
It is a valid domain, but reserved by RFC to be used for documentation.
Contoso.com is a dummy domain that can be used for testing.
It's used by Microsoft as an example whenever they need an example company or domain. They're the ones who registered it, and they use it frequently in their examples, so I doubt they care if you use it for testing. They likely ignore anything that goes it seeing as how its posted all over the web and a likely target for spam.
Frankly, I utilize an email address from my own testing email server for this because part of the testing is to ensure that the form information actually gets to the email address, and since checking it is outside of my normal work-flow, that means I have to actively do so.
We are using .local domains for that.
For testing purposes I like to have e-mail addresses that really do not exist and cannot be registered. Even access by IANA like for example.com is a no-go for security reasons. Accidently sent e-mails to max.mustermann#example.com maybe be delivered to servers controlled by IANA. This maybe an privacy issue for Max Mustermann and so on ...
Do not treat me wrong: This is just for additional security minimizing the risks whereever possible.
guerillamail.com for example is blocked by several blacklists (like http://www.block-disposable-email.com). So maybe it's better to use contoso.com.
you could configure your in house MTA to discard all example.com/net/org emails. you can be sure that no one would expect them to be delivered. and that would save your server from using resources and wasting bandwidth.
If it's email you want to test, why not use a disposable email address, such as GuerrilaMail? You can send an email to anyone#guerrillamail.com, or set your own user name, for a limited amount of time.BTW, Contoso is a Microsoft dummy site they've been using to demo .Net technologies for a couple of years now.