Frequently Asked Questions
Technical Email Issues
If you are already a client, please log in to your account as additional (and expanded) FAQ entries are available to you.
Encode Your Email to Reduce Spam
Automated harvesting of openly exposed email addresses is widely regarded as the leading spam generating vulnerability today. Such exposed
addresses are very easy to collect and are practically guaranteed to be valid and working addresses.
Furthermore, addresses harvested in this manner they are easily sorted by industry classification (based on the Web sites from which they
are taken) for sales within targeted email marketing lists.
To help combat this problem and enable Webmasters and site owners to easily close this widely-exploited vulnerability, the OnlyMyEmail
"mailto:" link, but address harvesting bots will not.
The OnlyMyEmail Encoder can be accessed and used by anyone, free of charge, through our collection of DNS Tools found at:
Spam Detection Rates, What the Numbers Don’t Tell You
Anyone who has looked for an email anti-spam solution is probably familiar with spam capture rate statistics. You’ve no doubt seen
claims such as “Blocks 99.9% of spam” but what the capture rate doesn’t tell you is going to prove even more important to your
overall filtering satisfaction.
While some spam campaigns are innovative and can be difficult for various filtering systems to catch, stopping most spam email is not too
difficult. The real challenge is NOT filtering the good mail that end users want to receive in the process.
A spam filter’s claimed capture rate means nothing if you do not know their false-positive rate. False positives are good emails
caught by the filters and marked as spam. A great capture rate will not be acceptable to the end-user if it comes with a high false-positive
rate. The cost of lost opportunities and delayed responses to legitimate mail will exceed the benefit provided by the blocking of spam.
This aspect of filtering is so important that false-positive rates are the single most important factor the OnlyMyEmail Anti-Spam team
considers when evaluating new filtering tactics and techniques.
To further complicate matters, not all false-positives are created equal. As long as users can easily train the filter to allow such emails
in the future, they are pretty tolerant when it comes to blocking commercial emails such as a Costco, Expedia or Bank of America advertisements.
They won’t even complain much if you occasionally trap high volume newsletters from ESPN, Motley Fool or MSNBC.
But if your filtering blocks legitimate user-to-user or critical automated e-commerce emails then the solution will be deemed
unacceptable. Because of this distinction, capture rates must be balanced not only against potential false-positive rates in general,
but “critical” false-positive rates as well.
Finally, in order to provide a positive end-user experience, the filtering system needs to be able to accommodate individual end-user
preferences with minimal human intervention. Because not all users will agree on a single definition of spam, the best solutions allow input
from users as to the types of email they individually want to receive, as well as those they want blocked.
For example, if you ask a handful of users about the the types of commercial emails referenced above, those from Costco, Expedia or ESPN,
you will find that while many consider such emails valid, others will consider them spam. Because of this, no filtering solution can truly provide
a useful and meaningful level of end-user satisfaction unless it can accommodate, on an individual level, which users consider what types of
commercial mail to be spam and which users actually prefer to receive those kinds of messages.
While some systems attempt to provide end-user control by simply providing “Whitelists” and “Blacklists” in the
real world these prove to be nothing more than error-prone band-aids because they cannot distinguish between legitimate emails from
Support@Ebay.com, for example, and those from spammers that simply “spoof” the same address.
The ability of a spam solution to make decisions based on end-user preferences, with significant focus on not only blocking spam but on
preventing false-positives, and to do so with minimal end-user effort, is what makes spam filtering such a complicated business.
“Effectively Perfect” Spam Filtering Hype
a team of computer scientists at the
International Computer Science Institute
in Berkeley, has developed an “effectively perfect” method of filtering spam from botnets. The system works by reverse
engineering the spam bot’s template to predict how it will vary messages in order to fool filters:
As spam is churned out, subtle changes are typically incorporated into the messages to confound spam filters. Each message is generated
from a template that specifies the message content and how it should be varied. The team reasoned that analyzing such messages could reveal
the template that created them. And since the spam template describes the entire range of the emails a bot will send, possessing it might
provide a watertight method of blocking spam from that bot.
The hype around this tactic assumes that no one else has already implemented it (if we have, we’re not telling). Obviously this would
be a good weapon in anyone’s anti-spam arsenal but touting it as “effectively perfect” is a bit hyperbolic. This tactic also
fails to consider that the spammer’s templates themselves can also be designed to randomly mutate, thus making reverse engineering a
much more difficult task, and dependent upon access to a large enough data sample.
The spam war has always been an escalating arms race. Whenever a “perfect” anti-spam tactic is developed elite spammers soon
find a way to circumvent it. Shortly thereafter the technology finds its way to less resourceful spammers and the status quo is maintained.
Our own spam control system depends on
continuous analysis of various existing spam attack vectors as well as identifying and responding to new spam tactics. Like the influenza
virus, spam constantly evolves in order to survive. Accordingly, spam control techniques also evolve.
Eventually we hope to find a cure for spam. Until then we’ll just have to settle for doing a really good job of controlling it.
Should ISPs Block Port 25?
According to ISPreview,
Trend Micro has apparently agitated British ISP’s by suggesting that they block their user’s port 25 SMTP access to external mail
servers (connections to the ISP’s own mail servers would not be affected).
The suggestion was offered as a tactic to prevent botnets of infected personal computers from connecting to external mail servers, which is
how many spammers send such massive amounts of junk email.
Interestingly, a number of articles and blog posts have been published recently that stand in opposition to this proposal, such as these
articles on AllSpammedUp and
Most of what we’ve read on the subject so far doesn’t answer the question as to whether blocking Port 25 is a good idea or not.
What is clear is that very few people, even those with technical backgrounds, actually understand the issue.
Positions taken against blocking port 25 include claims that such blocking would:
- Force sending email only through ISP mail servers greatly inconveniencing users who wish to send mail through accounts they may have
through work, schools or other organizations.
- Result in spammers shifting tactics to abuse other vulnerabilities, such as social networks.
- Be ineffective because most SMTP servers also accept connections on ports 465 and 587.
- Increase virus risks because: “Many anti-virus programs monitor port 25 by default, so blocking this port would leave users
unprotected unless they manually change their security software settings.”
- Create unspecified problems: “there is the possibility that the system will go wrong and block other things by mistake.”
With such a mixed bag of misinformation it’s easy to see why there is still debate on the issue. How can the facts be reasonably
discussed when so few know what they are?
For the record, and to correct one erroneous point at a time:
- Simply put, users don’t need access to port 25 in order to send mail. Almost any current email client can send outbound mail through
the mail server of your choice using port 587. This being the actual port, as specified by
RFC 4409 for such client submission. Enabling the use
of port 587 typically only requires that the user select “Alternate Submission Port” in their client, if any effort is required at all.
Because of RFC 4409 more and more email clients now automatically try 587 first, and only fall back to 25 if that is unavailable.
- Claiming that Port 25 should be left open for spammer’s botnets to exploit so they don’t move on to more sophisticated techniques
is laughable at best. It’s a “non” argument that could be used as disingenuous support against any and every spam filtering or
virus detecting technique ever conceived; and it would be equally specious in every case.
- It is true that many email servers (though not all) will accept SMTP to port 465 without authentication. It’s also true that spammers
might very well modify their botnets to exploit this. For that reason, 465 should be blocked as well. Since it was never
intended for SMTP
that’s no real loss to anyone, either. By contrast, when submitting to port 587, a properly configured mail server will require the user
to authenticate with a valid login and password and therein lies the key distinction. Allowing unrestricted access to 25/465 enables spammers to
send email without any authentication, whereas 587 does not. Thus, while real users can still send mail through the server of their choice using
port 587 (assuming they have the right to do so) infected zombies cannot.
- The statement that “Many anti-virus programs monitor port 25 by default” might be true for mail servers, which both send and
receive mail on Port 25. However, personal computers and other devices that are not mail servers receive their mail through ports 110, 143, 993, or 995.
There is nothing on a personal computer that should be listening to port 25 and no security vulnerability created by using alternate ports for
sending outbound mail.
- As for the “possibility that the system will go wrong and block other things by mistake” it should suffice to point out that
port 25 is only used for email, so this generic and uninformed fear of change is really just that.
While other weak and inaccurate positions can likely be put forth against port 25 blocking, there is not much substance to any of them. The
only somewhat valid argument that can be advanced is that blocking port 25 would make it more difficult to run an actual mail server on a PC
connected through a residential broadband connection. This obviously doesn’t effect the average user, whether business or residential, but
is commonly put forth by techies who like to run mail servers on their home PCs… mostly just because they can.
In cases where a user wishes to run a mail server out of their basement or small office, their ISP could unblock port 25 for that connection,
or they could configure their server to relay its mail through their ISP or another party via the submission port.
On the other hand, there is actually quite a bit of benefit to having ISPs block port 25 in that it neutralizes spam sending ability of most
infected personal computers.
In order to understand this, you need only grasp a few key points:
- ISP’s almost always allow access to their own mail servers through ports 25, 465 and also 587, so the only user that’s affected
by any of this discussion is the one who wants to connect to the Internet through their ISP but who wants to send mail through some external mail
- In those instances, the user’s email client software can submit to the mail server of their choice using the RFC specified port 587.
A properly configured server will require the client authenticate on this port which keeps the zombies out, while allowing real users in.
- Mail servers communicate with other mail servers using port 25. Allowing unrestricted access to external servers through port 25 just permits
infected PC’s to pretend they are mail servers, sending mail directly to any other mail server on the Internet without having to have email
access, authentication or privileges on any legitimate system.
- ISP blocking of port 25/465 cripples the existing zombie botnets, leaving them unable to spam, but has no effect whatsoever on mail server
to mail server traffic.
While blocking Port 25/465 won’t end spam, it will absolutely make it much more difficult for spammers to send the volume of email
they currently do using infected PCs.
It will also have the effect of sparing a lot of small business from having their mail servers relentlessly pounded to the point of crawling
or crashing altogether. As it now stands, millions of infected PCs can open mail server connections to any businesses mail server simultaneously,
overwhelming bandwidth and CPU resources while also crowding out connections from legitimate mail servers attempting to deliver real email.
It’s also worth noting that many if not most of the major broadband providers in the United States (and elsewhere) already do block
unrestricted access to external mail servers over port 25 and few if any end-users are inconvenienced or even know the difference.
Domain Name Disputes
If you own a domain or are listed as one of the contacts for a registered domain, it’s likely that you’ve been notified at least
once about a “domain name dispute”.
Domain name dispute fraud is an interesting breed of
These scams tend to originate in Asia and claim to be from an Asian domain registrar that is proactively notifying you that someone is trying
to register your domain name on one or more Asian
top level domains (TLDs).
They capitalize on the fact that a lot of domain owners know very little about what domain ownership entails or even how their domain got
registered in the first place. Consequently the targets of this type of fraud are liable to believe that not registering with the Asian TLDs
will dilute their brand.
A typical domain dispute fraud email looks like the following (we replaced the name of the company that this was sent to
Subject: Domain Name Disputes
From: “Robinson Zhou”<firstname.lastname@example.org>
(If you are not in charge of this please transfer this urgent email to your CEO, thanks.)
We are a company of Domain registration service in China,have something need to confirm with you.We formally received an application
on Mar.2nd,2010.One company which called “DM Investment Co. LTD” are applying to register ” fictionalco” as NET brand
But we find that “DM Investment Co. LTD” is not the original owner of the brand and trademark in the checking period,which
belong to your company.so I need confirm with you .whether your company authorized that company to register these domain names.If you have done
that,We will finish the registration for them and link to their website.
If not ,please let me know ASAP.
In addition, we hereby affirm that our time limit for dissent application is 7 workdays.If your company files have no dissent within those
days,we will unconditionally approve the application.
Address: Room 201, No.45,Building 14, Pujiang Garden,Lane 303 Huhang Highway,Fengxian District,Shanghai. 201401
Unlike so many fraud emails, this message actually has a reasonable “Subject:”, i.e. it’s not all capitalized; doesn’t have
tons of exclamation points and isn’t from Dr. David (or some other first name). The “From” is fairly average but
the “To:” is for “info”<email@example.com>”. This contains two clues:
- Info@fictionalco.com is not one of the listed contacts for the domain (in fact the real domain that this was sent to is using
whois privacy so nobody can find out
who the contacts are).
- The “info” address is a very likely to have been scraped from the company web site by an automated email address harvesting
program. Note: you can prevent this from happening to your email addresses by using the OnlyMyEmail Encoder, which is a free tool we provide
The next clue is the first line of the message which makes the following request:
(If you are not in charge of this please transfer this urgent email to your CEO, thanks.)
Like the CEO is going to handle domain registration. Yeah right.
The main body of the message suffers from the same language issues that are seen in many other types of fraud emails: incorrect punctuation,
spacing, capitalization and word usage. Apparently only legitimate businesses find it worthwhile to hire educated translators.
The most interesting thing about this type of fraud is that it originates from real Asian domain registrars. All of the contact
information traces back to Shengke Network Co.,Ltd (bad punctuation from their web site) and no attempt is made to direct the recipient of the
message to a specific contact.
Presumably whoever answers the phone is aware of this “business practice” and will gladly help you register the domain names in
question, probably at an exorbitant rate and for a long time (the Shengke website only allows registration periods of 5, 10 and 15 years).
Technically this isn’t fraud because you really get to register domain names with Asian TLDs (albeit expensively). On the other hand,
few businesses with registered domains actually need, or even have a use for domains on Asian TLDs. This is really just a way for unscrupulous
domain registrars to unload “unused inventory”.
Here’s what you need to know to make informed decisions about the above:
- The cost of domain registration from reputable registrars is currently around $5 to $15 per year for one domain. This is for domain
registration alone and does not include hosting, web design or other related services. $20/year is very expensive for domain registration.
(We’re looking at you Network Solutions.)
- Additional services like whois privacy or renewal synchronization may raise the price slightly; commitment to longer registration periods
may lower it.
- Many registrars require a two year commitment for the initial registration but will allow singly year registrations after that. Registrars
that require longer initial registrations (like the one above) should be avoided.
- Whois tools can be
found all over the web and used to look up the owner/availability of domains. Alternatively, typing the domain into a browser will often reveal
whether or not the domain is registered. None of the domains in the above list are registered as of this writing and any of them could be registered
with a more reputable registrar.
- If you want to protect your brand, acquiring .com, .org, .net and .biz versions is probably sufficient unless you have a large presence in an
area serviced by a different TLD like .com.tw (Taiwan) or .co.uk (UK).
- All TLDs are reachable by the entire Internet so no matter what TLD your domain has it’s visible to the whole world with the exception
of possible censoring by more repressive governments. (The country of Tuvalu has made a business of selling their country TLD (.tv) world-wide and
domains like del.ico.us make words by using alternate TLDs.)
- Domain naming is controlled by the Internet Corporation for Assigned Names and Numbers
(ICANN) and not by individual registrars.
Real domain name disputes are quite common but they always arise after someone has registered the domain. The legal issues surrounding the
question of whether first come first served registration takes precedence over recognizable brand names are still being worked out. Recognizable
brand names have the advantage though, because they tend to have more money for lawyers.
For more information on domain name disputes see the following:
ICANN Domain Name Dispute Resolution Policy
BitLaw – Domain Name Dispute Section
Wikipedia – Uniform Domain Name Dispute Resolution Policy
Are You Being Tracked?
There’s more to spam than just banging out a million emails a day. If at all possible you want those emails to go to addresses that
are active so people will see your spam. Because of this, spammers, like any other marketers, want to know if anybody looks at their “ads”.
Not all spammers keep clean lists but if your address cannot be identified as active, it will most likely be dropped by the ones that do.
And, the less your address is circulated by spammers, the less spam you’ll get.
The two most popular techniques for tracking spam campaigns are:
- Tracking Links
- Tracking Images
Both can be avoided with minimal effort.
If you check out what the “Free Porn” link in the spam you just got
actually refers to
you’ll often see something like this:<
The main thing to notice in the examples above is the group of random characters which serves as a unique identifier for the address the
message was sent to. When the spam messages are generated each one gets an ID that will be stored in a database along with the email address
it was sent to. By monitoring the web server logs at spamexample.com the spammer can tell which addresses clicks came from.
The simplest way to avoid being tracked by links in email messages is just not clicking them. (BTW this applies to so-called legitimate
advertising as well.) If you don’t click the link, no request will be sent to the spammer’s web server and they won’t know you
saw the email.
A trickier way of tracking messages is by including links to images in the message
HTML. When presented with an image link, some
email clients will automatically
request a copy of the image from the server where it resides. Using the same random identifier trick mentioned above with the image link the
spammer can tell you opened the message as soon as you download the image. The really sneaky part is that you won’t usually know you
downloaded the image.
Newer email clients will, by default, wait for your approval before retrieving remote images and will usually say something like “For
your protection images in this message were not downloaded.” This prevents the email message from automatically identifying your address
for the spammer. If your client is doing this you have nothing to worry about as long as you’re not telling the client that you want to
see the images. If you are asking the client to get the images you’re asking to be tracked.
If you have an email client that downloads all images by default you’ll need to look for the setting that tells it not to. If your
client does not allow you to disable image downloading you should use a different client. Unfortunately, detailed instructions for this are
beyond the scope of this post. If you can’t figure it out, try to enlist your neighborhood geek:)
Avoid being tracked by spammers by resisting the urge to click on their links and make sure your email client asks you before downloading images.
Currently not permitted to relay through this server – Worst Rejection Ever!
Of all the confusing and convoluted mail server rejections commonly in use, “Currently not permitted to relay through this server”
causes more Support tickets for us than any other. Worse yet, it’s not even an error that we use, so we find ourselves constantly trying to
coherently explain what someone else’s mail server is saying.
Given that this is arguably the worst mail server error message ever, we’re going to try to make sense of it once and for all.
When reviewing the following example, realize that the IP addresses and server names will change to reflect the server that is sending the
email and also the one which is refusing to accept it. We’re replacing the receiving/rejecting server IP with 184.108.40.206 and the
sending server’s IP with 220.127.116.11.
Also note that the layout and formatting for these rejections can often be confusing as well, with lots of line breaks and
“550′s” scattered about.
Disclaimers aside, this ugly bounce/rejection/NDR message typically says:
SMTP error from remote mail server after RCPT TO:: host 18.104.22.168:
your-mailserver.com [22.214.171.124]: is currently not permitted to relay through this server.
Perhaps you have not logged into the pop/imap server in the last 30 minutes or do not have SMTP Authentication turned on in your email client.
While the language is fairly uncomplicated, at the same time it’s also impossibly confusing for the average user to decipher. Further,
because of the dual nature of this error message, it actually confuses many experienced email and network admins too.
What on earth does this mean?
While the “currently not permitted to relay through this server” is a convoluted explanation, what it means is that the
receiving server doesn’t believe that it is supposed to accept messages for the recipient domain, so it’s refusing/rejecting the
email you sent.
Instead, the recipient server thinks that you’re trying to use it to deliver/relay messages to some outside domain for which it is
Usually this is seen after someone manually changes settings on a mail server or some automatic update is applied and the server which used
to happily accept mail for “recipient.com” no longer thinks it’s supposed to host mail for them and rejects with this error
If this is the case, then someone in the email admin or support group will need to work on the recipient’s mail server to reconfigure
it to once again accept mail for the recipient domain.
On the other hand….
On the other hand, these error messages also contemplate that perhaps you’re not some outside mail-server trying to deliver inbound
mail, but instead you might be a local user with a mail account on the server who is trying to send outbound email via SMTP but you (or your
email software) forgot to login and authenticate.
The fact of the matter is that most mail-servers cannot actually tell the difference between another mail-server connecting to deliver
inbound mail or an individual user who is connecting to send outbound mail. That may sound hard to believe, but it’s sadly true.
And that is why this part is confusingly tacked added to the end of the rejection:
Perhaps you have not logged into the pop/imap server in the last 30 minutes or do not have SMTP Authentication turned on
in your email client.
Having this one rejection message trying to cover two completely different scenarios, combined with the most confusing of language, is what
causes so many problems and misunderstanding.
Now, given that the above explanation still might not make perfect sense to the average user, let’s re-write the rejection to say
what it really means:
We’re sorry, our server will not accept your message.
If you are a mail-server connecting to our system to deliver this message to us, then please be aware that our servers are not configured
to accept mail for the recipient’s domain.
If you are a local user, trying to send this email outbound for delivery, the problem is that we don’t see you as having logged
into the SMTP server. Please download/check for new mail before sending, and you might also need to configure your email software to use
If that doesn’t work, you might need to restart your email client software.
Granted this still probably won’t make perfect sense to someone with no knowledge of how email actually works, but it’s
hopefully a lot clearer for the rest of us.
If restarting the mail client and configuring it for SMTP Authentication don’t get you past this error, then again, someone in the
admin or support department for your domain will have to verify your account status and/or check their SMTP logs to figure out why your mail
server is still rejecting your connections.
What is a Mail Exchanger (MX) Record?
Unlike a postal address, which contains several pieces of information (name, house/apt. number, street, city, state, ZIP code) about where
postal mail should be delivered, an email address only provides two pieces of data: the mailbox ID and the domain name.
These are neatly separated by the & sign with the mailbox ID to the left and the domain name to the right. If your address is
username&OnlyMyEmail.com then your mailbox ID is username and the domain name is OnlyMyEmail.com.
Fortunately, given how email works, this
is enough to ensure accurate delivery.
From the perspective of the Internet at large, the domain name is really all that matters. It’s up to the server that handles email
for a given domain to determine which mailbox should receive the message. All the sending server needs to know in order to deliver a message
is the recipient domain.
Since the right-hand side of an email address is the domain name, this is easy enough to figure out. Unfortunately, computers don’t
really understand domain names the way people do. What computers understand is
This little fly in the ointment is due to the fact that IP addresses like 126.96.36.199 work great for computers but all those digits
don’t make sense to us humans. To us, OnlyMyEmail.com is much easier to remember than 188.8.131.52. So the trick is to have
people use domain names and computers use IP addresses.
The Domain Name System (DNS) bridges
the gap between human readable domain names and computer friendly IP addresses by mapping domain names to IP addresses. Every domain has a set
of DNS records that connect its name to the IP addresses of the servers that supply services for the domain. These records are stored on the
Name Server for the domain and made available to the world so that the domain can be located.
So What About MX Records?
MX records are a specific type of DNS record used to locate the mail exchanger (M as in Mail and X as in eXchanger) for the domain specified
in the domain name side of the email address. The mail exchanger is any computer configured to accept delivery of email for that domain.
When email is delivered, the destination server is determined by looking up the MX records for the domain and sending the email to the targets
specified in therein.
A typical set of MX records will look like this:
onlymyemail.com. 300 IN MX 10 mailfilter1.onlymyemail.com.
onlymyemail.com. 300 IN MX 20 mailfilter2.onlymyemail.com.
onlymyemail.com. 300 IN MX 30 mailfilter3.onlymyemail.com.
onlymyemail.com. 300 IN MX 40 mailfilter4.onlymyemail.com.
Each line is a single MX record and each domain can have several. This allows the owner of the domain to specify more than one server that
will accept delivery. Multiple servers may be desirable in situations where several servers share the load for one domain, as backup servers
MX records consist of the following (from left to right):
- Domain Name – This is the name of the domain to which the record belongs. The trailing dot (.) at the end of the
domain name is required.
- Time To Live (TTL) – In order to avoid constantly looking things up, the results of DNS lookups are usually saved
(cached) by the machine doing the looking. TTL is the number of seconds that can pass before the record has to be looked up again.
- Class – Allows DNS records to be used for networks other than the Internet. Since this is rare, class is pretty
much always IN for Internet.
- Type – For MX records type will always be MX . That’s why they’re MX records (as opposed to
A or NS records).
- Priority/Preference – This establishes the order in which servers should be contacted when there are multiple MX
records with multiple servers.
- Target – The hostname of the computer where mail should be delivered. This also requires the trailing dot (.) to
Editing MX Records
DNS records are generally maintained by the hosting provider for a domain or, for domains that handle their own DNS, by the IT staff of
the domain owner.
Note: When DNS records are not maintained in-house they must be accessed using the interface provided by the hosting service. This may
allow the editing of individual fields in the records, line by line editing of record sets or a facility to upload files containing DNS
records. Since DNS editing interfaces are all slightly different, a click-by-click how-to would occupy several volumes. For the sake of brevity
just keep in mind that each line in a set of MX records for a domain represents a way to deliver mail to that domain.
The usual reason for editing MX records is to change where email is delivered for a domain. This is often done to have email sent to a
company owned email server or an email service provider
Sometimes MX records have to be edited to re-establish these services after changing web hosting as web hosting providers will often reset
the MX records of newly hosted domains to point to their own mail exchangers.
Of the six fields in an MX record only three make sense to change. Changing the domain name makes the record for a different domain; the
type must remain MX or the record ceases to be an MX record and the class is always IN.
This leaves TTL, priority and target available to change.
Time To Live (TTL)
TTL is frequently 86400 which is 60 X 60 X 24 seconds or the number of seconds in a day. This means that the longest it can take for cached
copies of your MX records to update is 24 hours. This is normally quite effective since MX records don’t change very often.
However, it can be useful to update the TTLs on MX records in advance of a change in order to make them propagate faster during the change.
Lowering the TTL to 300 (5 minutes) a day before making the actual MX changes will cause cached records to be updated in 5 minutes instead
of 24 hours and make mistakes reveal themselves much sooner. Once the changes are proven correct, TTLs should be set back to 864000 to keep
the hosting server from being deluged by DNS cache update requests.
Both priority and preference are likely terms for this field. Either way the field should contain a decimal integer
(a.k.a. a number). Records with lower numbers are tried first, thus a record with a priority of 10 would be tried before a record with a
priority of 20.
It is generally recommended to number in increments of 10 or so to allow new records to be inserted between older ones without having
to renumber all of the subsequent records. For instance, if your preference settings are 0, 1, 2, 3 and you want to add a new highest
priority server you have to raise all of the other priorities by 1. Whereas, if your preferences are 10, 20, 30, 40 you could stick in a new
highest priority server by setting it’s priority to 5 without touching any of the other records.
The target is the most critical of the editable fields in an MX record. TTL and priority/preference can be off by a little (as long
as they’re numbers) without interrupting mail delivery. Target on the other hand has to be perfect or it won’t work.
First, the target must be a
Fully Qualified Domain Name (FQDN).
In this context the the outstanding feature of the FQDN is that it includes the trailing dot. If the trailing dot is omitted the hostname
won’t work. (Some interfaces will catch this and fix it but don’t count on it.)
Spelling is also important. Computers don’t gloss over spelling errors the way humans do. It only takes one incorrect character to
cause mail delivery to fail, or worse, deliver mail to the wrong domain.
Finally, it is important to note that some interfaces will allow the use of an IP address instead of a domain name. While this may actually
work, it is contrary to the DNS specification (see IETF RFCs
and may cause email from your domain to be rejected by mail servers that are strict about RFC compliance. This can be extremely difficult
to troubleshoot because it only causes intermittent failures. It is much better to avoid this problem altogether by using FQDNs instead
of IPs in MX records.
Verifying MX Records
Most hosting providers will tell you what they think your MX records are but it can be worthwhile to get a second opinion. Finding and using a good MX lookup tool (or several) will often help with troubleshooting by revealing discrepancies between what you think is in your MX records and what is actually returned by a routine MX lookup request for your domain.
Wikipedia – MX Records
What Are False-Positive Emails?
When spam filtering systems block the delivery of a legitimate email, this is referred to as a “false-positive” result.
As it turns out, doing a good job of stopping Spam is not nearly as difficult as avoiding false-positives results. Eliminating
false-positives is the most difficult problem for email recognition and filtering technologies, and is what separates the better mail
filtering solutions from the rest.
A realistic expectation is that every useful spam filtering system or technique will create false-positives, and especially with regards
to automated notifications, mass-mailed commercial newsletters and “legitimate” direct marketing messages.
Regardless of marketing claims, these types of false-positives are unavoidable simply because automated and mass mail systems seldom verify
that the addresses they are sending to are legitimate, or that the recipients specifically requested such promotional emails in the first place.
As a result, they often send to recipients who never subscribed, and this results in those emails being reported as spam.
Further, as a practical matter and in real-world applications, few users really care if a hobby newsletter or credit card marketing offer
from Amazon.com is delayed or deleted by their spam filter, as long as such instances can be easily discovered and corrected so they do not
occur again in the future.
On the other hand, the delay or deletion of personal or business communication or a transactional confirmation or receipt can often have
significant negative consequences, such as missed appointments, lost opportunities or damaged business or personal relationships.
With this in mind, the real measure of performance and accuracy when it comes to blocking legitimate emails is the measurement of what can
be referred to as “critical false-positives.” These can be loosely defined as the blocking of human to human correspondence or
legitimate (and specifically non-mass mailed) notifications such as purchase confirmations and other transactional emails that are event specific
and unique to the recipient.
Unfortunately, all third-party testing that we’ve seen to date, including online reviews and other comparative analysis, simply
don’t do a very good job of accurately making this distinction, if they even attempt to measure critical false-positives” at all.
The result is that while such analysis and review can often be very accurate as it relates to spam-capture rates, when it comes to measuring
critical false-positives you’ll need to evaluate them for yourself.
The only reliable guide is going to be experience, typically base on a live-trial of various filtering solutions in order to see how they
perform in the real world, and against your organizations unique email stream.
Other FAQ Sections:
MX-Defender for business/corporate/enterprise
Technical Email Issues
Understanding Email Basics
If you don't find the answer you're looking for here, please email your question to: