Hi Chandran,

This email landed in my spam folder sorry to say (gmail).

Never set up a DMARC record...any tutorials you recommend (anyone)?

Eric

On Wed, Aug 28, 2019 at 10:16 PM ChandranManikandan <kand...@gmail.com>
wrote:

> Hi Friends,
>
> I have updated SPF and DMARC record into my DNS server after that the
> email is delivered to inbox instead spam/junk folder.
>
> Please try to create SPF and DMARC record in your DNS servers
>
> On Wed, Aug 28, 2019 at 11:39 AM ChandranManikandan <kand...@gmail.com>
> wrote:
>
>> Hi Friends,
>>
>> As per Andrew stats, i have checked all those points in my server.
>> I have installed letsencrypt certificate in past two years without any
>> issue and spf record validated and configured on the DNS server.
>> DKIM also installed on my server well.
>>
>> When users send an email to gmail, some emails are going to inbox and
>> some going to spam with the same my domain.
>>
>> I have no clue to setup the dmarc record in the dns server.
>>
>> Could anyone help me for the process of creating dmarc record.
>> Do i need to create my server or dns server.
>>
>> My domain result for the reputation.
>>
>> MEDIUM REPUTATION
>>
>> Not suspicious. We have not seen any direct references to this email
>> address, but the sender domain is highly reputable, and the email is
>> deliverable. We've observed no malicious or suspicious activity from this
>> address.
>>
>>
>>
>> curl emailrep.io/m...@panasiagroup.net
>>
>> {
>>
>>     "email": "x...@xxx.net",
>>
>>     "reputation": "medium",
>>
>>     "suspicious": false,
>>
>>     "references": 0,
>>
>>     "details": {
>>
>>         "blacklisted": false,
>>
>>         "malicious_activity": false,
>>
>>         "malicious_activity_recent": false,
>>
>>         "credentials_leaked": false,
>>
>>         "credentials_leaked_recent": false,
>>
>>         "data_breach": false,
>>
>>         "first_seen": "never",
>>
>>         "last_seen": "never",
>>
>>         "domain_exists": true,
>>
>>         "domain_reputation": "high",
>>
>>         "new_domain": false,
>>
>>         "days_since_domain_creation": 5524,
>>
>>         "suspicious_tld": false,
>>
>>         "spam": false,
>>
>>         "free_provider": false,
>>
>>         "disposable": false,
>>
>>         "deliverable": true,
>>
>>         "accept_all": false,
>>
>>         "valid_mx": true,
>>
>>         "spoofable": true,
>>
>>         "spf_strict": true,
>>
>>         "dmarc_enforced": false,
>>
>>         "profiles": []
>>
>>     }
>>
>> }
>>
>>
>> Appreciate of all your supporting.
>>
>> On Wed, Aug 28, 2019 at 8:49 AM Andrew Swartz <awswa...@acsalaska.net>
>> wrote:
>>
>>> This seems an issue mostly with server "suspiciousness", of which
>>> reputation is a component.
>>>
>>> Of the factors effecting suspiciousness, only two are local to the smtp
>>> server:
>>> 1.  DKIM signatures
>>> 2.  TLS certificates
>>>
>>> To address these, confirm that both are working properly:
>>> 1.  DKIM: send an email to a "dkim reflector" and then examine the email
>>> you get back.  This pages discusses:
>>>
>>> https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118571-technote-esa-00.html
>>>
>>> 2.  Use a proper TLS certificate.  By proper, I mean one that verifies.
>>> Therefore you need to either purchase one or use "Let's Encrypt".  I've
>>> been using Lets Encrypt certs for the last year without any problems.
>>> Setting up the client is not difficult, and it subsequently auto-renews
>>> every 60 days.
>>>
>>> The remaining factors are outside your server, but just as important:
>>> 1.  Reverse-DNS yields same result as the domain MX record.  This is
>>> known as FCRDNS (forward-confirmed reverse DNS).  Additionally, that
>>> result must not resemble a dynamic IP address (i.e. have the IP address
>>> in the domain name).
>>> 2.  SPF is properly set up.
>>> 3.  DMARC set up and working properly.
>>> 4.  Age of the domain name.  If created recently, that looks bad.
>>> 5.  Presence of IP on blacklists.  That is not hard to check.  If you
>>> acquired an IP recently, it's former owner may have earned it a place on
>>> a blacklist.  Easiest fix for that seems to be to get a different IP.
>>>
>>> I'm curious to hear what others might add to this.
>>>
>>> A good place for ideas is to browse through the spamdyke.conf file and
>>> think about all of the things it checks.  Gmail is certainly using
>>> similar data points, but with neural network analysis rather than simple
>>> pass/fail rules.
>>>
>>> For those who have set up a second server to test things, there is a
>>> good chance something above is not set up or does not support the new
>>> server.  Gone are the days when you can bring a new parallel server
>>> online and start sending mails immediately.  There are lots of "i's" to
>>> dot and "t's" to cross before other servers will confidently accept your
>>> mail.
>>>
>>> Another thought:
>>> https://emailrep.io/ will give you a report about an email ADDRESS's
>>> reputation.  It is interesting.  Here is the result for mine (I replaced
>>> my email address for posting):
>>>
>>> curl emailrep.io/first.l...@example.tld
>>> {
>>>      "email": "first.l...@example.tld",
>>>      "reputation": "low",
>>>      "suspicious": true,
>>>      "references": 1,
>>>      "details": {
>>>          "blacklisted": false,
>>>          "malicious_activity": false,
>>>          "malicious_activity_recent": false,
>>>          "credentials_leaked": false,
>>>          "credentials_leaked_recent": false,
>>>          "data_breach": false,
>>>          "first_seen": "never",
>>>          "last_seen": "never",
>>>          "domain_exists": true,
>>>          "domain_reputation": "low",
>>>          "new_domain": false,
>>>          "days_since_domain_creation": 5654,
>>>          "suspicious_tld": false,
>>>          "spam": false,
>>>          "free_provider": false,
>>>          "disposable": false,
>>>          "deliverable": false,
>>>          "accept_all": false,
>>>          "valid_mx": true,
>>>          "spoofable": false,
>>>          "spf_strict": true,
>>>          "dmarc_enforced": true,
>>>          "profiles": []
>>>      }
>>> }
>>>
>>>
>>> Though my domain and address are over 10 years old and never been
>>> blacklisted, the address gets a "low" reputation.  I'm quite sure that
>>> is because it has determined that my email address cannot accept emails.
>>>   But it is incorrect.  After testing it a few times, I'm fairly
>>> confident that it decides that mostly because it tries to connect to my
>>> server from smtp25a.kickboxio.net, whose IP (72.249.58.154) is blocked
>>> by Spamdyke due to being on some blacklist.  Therefore it concludes that
>>> I'm "risky".  Also, they feel the risk is increased because my email has
>>> never been seen on social media, in credential breaches, etc.  But I
>>> feel it is a triumph that I've kept my email address off of places where
>>> spammers harvest addresses.
>>>
>>> Gmail is almost certainly considering all these factor and many more in
>>> deciding whether an email is rejected, sent to spam folder, or sent to
>>> inbox.  That said, my wife uses gmail and we send numerous emails back
>>> and forth daily without any problem.
>>>
>>> It used to be that setting up an smtp server was the hard part of
>>> running your own server.  But times have changed, and now factors
>>> external to your network seem far more complicated and consequential
>>> than the server itself.
>>>
>>> Again, I'm curious to hear other people thoughts.
>>>
>>>
>>> -Andy
>>>
>>> PS: regarding the question of multiple certs, I do not see how that
>>> could work on the toaster.  And in general, smtp does not work that way.
>>>   The cert merely needs to be for the domain name pointed to by the MX
>>> record of the destination domain.  There is no requirement that the
>>> destination domain be the name on the server certificate.  Thus numerous
>>> virtual domains all have MX records which point to the same server; that
>>> server's cert merely needs to be for its own domain name, not those of
>>> all its virtual domains.  For incoming mail, when connecting to a server
>>> and upgrading an smtp connection to a STARTTLS session, I don't think
>>> that the STARTTLS command has a way to specify the destination address's
>>> domain.  That would need to happen for a server to know which
>>> certificate to use.  For outgoing mail, it is theoretically easy to do,
>>> but someone would need to write a qmail patch to implement it.
>>>
>>> DKIM works differently: each virtual domain has it's own dkim signing
>>> key.  The toaster supports that, but it must be done manually (i.e. it
>>> does not occur when creating domains with vqadmin).  Adding that
>>> functionality into vqadmin might be a good project for someone.
>>>
>>> I did not intend for this to be so long.  It just happened.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 8/26/2019 11:05 PM, Remo Mattei wrote:
>>> > Ok guys.. needs some suggestions..
>>> > I found out that the client (apple Mail) does not honor the DKIM since
>>> > gmail said failed. I tested with Outlook and web round cube and that
>>> > does pass the email DKIM and the message does not go into the spam
>>> > folder in fact.
>>> >
>>> > Any help will be great.. I also wonder if there is a way to setup
>>> > multiple certs for the SMTP (per domain).
>>> >
>>> > Remo
>>> >
>>> >> On Aug 26, 2019, at 12:03, Tahnan Al Anas <tah...@gmail.com
>>> >> <mailto:tah...@gmail.com>> wrote:
>>> >>
>>> >> Basically Gmail put mail in spam folder for various reasons, I have
>>> >> found after hosing new domain in my qmail server, I need to check
>>> spf,
>>> >> dkim dmarc settings, even if all are ok, still gmail sent mail to
>>> spam
>>> >> folder, I need to check reverse forward record and also need to work
>>> >> to improve domain reputation, this is not an issue with qmail server,
>>> >> rather it is related with gmail's filtering. You have to work to
>>> >> improve server and domain's reputation for that.
>>> >>
>>> >> Sometime I chat with google to get my other domain's mail in inbox by
>>> >> sending them to gsuite account.
>>> >>
>>> >>
>>> >> --
>>> >> --
>>> >>
>>> >> Best Regards
>>> >> Muhammad Tahnan Al Anas
>>> >>
>>> >>
>>> >> On Mon, Aug 26, 2019 at 11:01 PM Eric Broch <ebroch.w...@gmail.com
>>> >> <mailto:ebroch.w...@gmail.com>> wrote:
>>> >>
>>> >>     Create a google (gmail) account if you don't have one. Send an
>>> >>     email to that account from the postmaster of the problematic
>>> >>     domain. Open message, go to three vertical dots to the upper right
>>> >>     of the interface, find 'show original', there you will see why
>>> >>     gmail spammed your message.
>>> >>
>>> >>     On Mon, Aug 26, 2019 at 10:51 AM Remo Mattei <r...@mattei.org
>>> >>     <mailto:r...@mattei.org>> wrote:
>>> >>
>>> >>         I just tested and I built a new qmail box
>>> >>
>>> >>
>>> >>         qmail-1.03-3.1.qt.el7.x86_64
>>> >>
>>> >>         The other two boxes
>>> >>         With
>>> >>         qmail-1.03-3.1.qt.el7.x86_64
>>> >>         qmail-1.03-3.1.qt.el7.x86_64
>>> >>
>>> >>         So when sending from the new env which does not have any load
>>> >>         no production etc.. the gmail gets the message in the inbox
>>> >>         from the other two I get the msg on the spam folder.. I
>>> >>         wonder.. how is Google…. Check the messages.. The new box I
>>> >>         have even a domain called testdomain.com
>>> >>         <http://testdomain.com/> which it’s bogus!! But still in the
>>> >>         inbox.
>>> >>
>>> >>         Any tips?
>>> >>
>>> >>         Thanks
>>> >>
>>> >>>         On Aug 25, 2019, at 21:10, ChandranManikandan
>>> >>>         <kand...@gmail.com <mailto:kand...@gmail.com>> wrote:
>>> >>>
>>> >>>         Hi Folks,
>>> >>>
>>> >>>         Emails are delivering to the spam or junk folder when users
>>> >>>         send to the recipients.
>>> >>>         Mostly  it's all public domain like gmail,yahoo etc..
>>> >>>         How to fix this issue in our server.
>>> >>>         Am using Centos 6 32 bit with qmailtoaster.
>>> >>>         Could anyone help me.
>>> >>>
>>> >>>         --
>>> >>>         */Regards,
>>> >>>         Manikandan.C
>>> >>>         /*
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>>>
>>>
>>
>> --
>>
>>
>> *Regards,Manikandan.C*
>>
>
>
> --
>
>
> *Regards,Manikandan.C*
>

Reply via email to